Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: #42: One of the arguments does not satisfy the requirements of the libfunc. #3863

Closed
enitrat opened this issue Aug 8, 2023 · 1 comment · Fixed by #3892
Closed

bug: #42: One of the arguments does not satisfy the requirements of the libfunc. #3863

enitrat opened this issue Aug 8, 2023 · 1 comment · Fixed by #3892
Labels
bug Something isn't working

Comments

@enitrat
Copy link
Contributor

enitrat commented Aug 8, 2023

Bug Report

Cairo version:
2.1.0

Current behavior:
Testing the following code results in:

testing bugreport ...
Error: Failed setting up runner.

Caused by:
    #42: One of the arguments does not satisfy the requirements of the libfunc.
error: process did not exit successfully: exit status: 1

The bug manifests when more than two assertion lines are present at a time. When only one is there, it runs successfully.
Expected behavior:
The test runs successfully

Steps to reproduce:

Related code:

use array::{ArrayTrait, SpanTrait};
use option::OptionTrait;
/// The call context.
#[derive(Destruct)]
struct CallContext {
    /// The bytecode to execute.
    bytecode: Span<u8>,
    /// The call data.
    call_data: Span<u8>,
    /// Amount of native token to transfer.
    value: u256,
}


trait CallContextTrait {
    fn new(bytecode: Span<u8>, call_data: Span<u8>, value: u256) -> CallContext;
    fn bytecode(self: @CallContext) -> Span<u8>;
    fn call_data(self: @CallContext) -> Span<u8>;
    fn value(self: @CallContext) -> u256;
}

impl CallContextImpl of CallContextTrait {
    fn new(bytecode: Span<u8>, call_data: Span<u8>, value: u256) -> CallContext {
        CallContext { bytecode, call_data, value,  }
    }
    fn bytecode(self: @CallContext) -> Span<u8> {
        *self.bytecode
    }

    fn call_data(self: @CallContext) -> Span<u8> {
        *self.call_data
    }

    fn value(self: @CallContext) -> u256 {
        *self.value
    }
}
impl SpanPartialEq<T, impl PartialEqImpl: PartialEq<T>> of PartialEq<Span<T>> {
    fn eq(lhs: @Span<T>, rhs: @Span<T>) -> bool {
        if (*lhs).len() != (*rhs).len() {
            return false;
        }
        let mut lhs_span = *lhs;
        let mut rhs_span = *rhs;
        loop {
            match lhs_span.pop_front() {
                Option::Some(lhs_v) => {
                    if lhs_v != rhs_span.pop_front().unwrap() {
                        break false;
                    }
                },
                Option::None => {
                    break true;
                },
            };
        }
    }
    fn ne(lhs: @Span<T>, rhs: @Span<T>) -> bool {
        !(lhs == rhs)
    }
}

#[test]
#[available_gas(1000000)]
fn test_call_context_new() {
    // Given
    let bytecode = array![1, 2, 3];
    let call_data = array![4, 5, 6];
    let value: u256 = 100;
    // When
    let call_context = CallContextTrait::new(bytecode.span(), call_data.span(), value);
    // Then
    assert(call_context.bytecode() == bytecode.span(), 'wrong bytecode');
    assert(call_context.call_data() == call_data.span(), 'wrong call data');
    assert(call_context.value() == value, 'wrong value');
}

Other information:

@enitrat enitrat added the bug Something isn't working label Aug 8, 2023
@orizi
Copy link
Collaborator

orizi commented Aug 9, 2023

I mostly understand why this happens - we apparently have an issue with the local variable scheduling:
If we have a variable returned from a function that needs to immediately be used, but should also be local, we convert it to local, while not repushing it onto the stack.

A temporary solve for these cases can be:
Add:

#[inline(never)]
fn no_op() {}

Call it write after the call to ::new.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants