cairo_native: BUG: parse result error

I’m getting an issue on the parse_result call at the end of the invocation of invoke_dynamic. Here is the backtrace:

thread 'evm_sequencer::evm_state::v1::tests::test_execute_simple_contract' panicked at /Users/greg/code/rust/cairo_native/src/values.rs:536:21:
assertion failed: length_value >= offset_value
stack backtrace:
   0: rust_begin_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
   2: core::panicking::panic
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:144:5
   3: cairo_native::values::JitValue::from_jit
             at /Users/greg/code/rust/cairo_native/src/values.rs:536:21
   4: cairo_native::values::JitValue::from_jit
             at /Users/greg/code/rust/cairo_native/src/values.rs:662:38
   5: cairo_native::executor::parse_result
             at /Users/greg/code/rust/cairo_native/src/executor.rs:706:37
   6: cairo_native::executor::invoke_dynamic
             at /Users/greg/code/rust/cairo_native/src/executor.rs:267:24
   7: cairo_native::executor::jit::JitNativeExecutor::invoke_contract_dynamic
             at /Users/greg/code/rust/cairo_native/src/executor/jit.rs:102:13
   8: starknet_in_rust::execution::execution_entry_point::ExecutionEntryPoint::native_execute
             at /Users/greg/code/rust/starknet_in_rust/src/execution/execution_entry_point.rs:777:46
   9: starknet_in_rust::execution::execution_entry_point::ExecutionEntryPoint::execute
             at /Users/greg/code/rust/starknet_in_rust/src/execution/execution_entry_point.rs:168:23
  10: starknet_in_rust::transaction::invoke_function::InvokeFunction::run_execute_entrypoint
             at /Users/greg/code/rust/starknet_in_rust/src/transaction/invoke_function.rs:335:9
  11: starknet_in_rust::transaction::invoke_function::InvokeFunction::apply
             at /Users/greg/code/rust/starknet_in_rust/src/transaction/invoke_function.rs:388:13
  12: starknet_in_rust::transaction::invoke_function::InvokeFunction::execute::{{closure}}
             at /Users/greg/code/rust/starknet_in_rust/src/transaction/invoke_function.rs:461:28
  13: starknet_in_rust::transaction::invoke_function::InvokeFunction::execute
             at /Users/greg/code/rust/starknet_in_rust/src/transaction/invoke_function.rs:425:5
  14: starknet_in_rust::transaction::Transaction::execute
             at /Users/greg/code/rust/starknet_in_rust/src/transaction/mod.rs:224:48
  15: <sequencer::sequencer::Sequencer<S> as sequencer::execution::Execution>::execute
             at /Users/greg/code/rust/ef-tests/crates/sequencer/src/sequencer.rs:73:19
  16: ef_testing::evm_sequencer::evm_state::v1::<impl ef_testing::evm_sequencer::evm_state::Evm for ef_testing::evm_sequencer::sequencer::KakarotSequencer>::execute_transaction
             at ./src/evm_sequencer/evm_state/v1.rs:260:9
  17: ef_testing::evm_sequencer::evm_state::v1::tests::test_execute_simple_contract
             at ./src/evm_sequencer/evm_state/v1.rs:357:9
  18: ef_testing::evm_sequencer::evm_state::v1::tests::test_execute_simple_contract::{{closure}}
             at ./src/evm_sequencer/evm_state/v1.rs:322:38
  19: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
  20: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
libunwind: malformed __unwind_info at 0x18DB5BCA8 bad second level page

This is from executing the test test_execute_simple_contract from the ef-tests repo on Kakarot.

About this issue

Original URL
State: closed
Created 3 months ago
Comments: 18 (10 by maintainers)

Most upvoted comments

Yes, but you only need the address where something starts to be aligned, not the address where something ends.

The problem was that we had an array ((ptr, u32, u32, u32)) followed by an u32 giving the following structure ((ptr, u32, u32, u32), u32). We had it implemented so that there was no padding after the structures. The final u32 would fit where the padding of the first struct is and still be properly aligned:

Type	Alignment	Size
ptr	8	8
u32	4	4
u32	4	4
u32	4	4
u32	4	4

The compiler, however, inserts the padding to the inner and outer structs as follows, wasting eight bytes of memory per instance:

Type	Alignment	Size
ptr	8	8
u32	4	4
u32	4	4
u32	4	4
padding	N/A	4
u32	4	4
padding	N/A	4

As you can see both of them are properly aligned, that’s why I don’t understand the decision about padding the struct’s end, but as I said before I’m probably missing some crucial information or edge case that would explain the padding.

azteca1998 on Apr 25, 2024

Just in case, can you try to update to the latest native commit?

edg-l on Apr 11, 2024

Weird, maybe I was on another commit, can check tmr. Here is the execute

https://github.com/kkrt-labs/kakarot-ssj/blob/main/crates/contracts/src/eoa.cairo

greged93 on Mar 28, 2024