bug: CI test with invalid memory reference

[DreamWuGit]

What command(s) is the bug in?

No response

Describe the bug

found this issue in PR #1265 's CI https://github.com/privacy-scaling-explorations/zkevm-circuits/actions/runs/4349281702/jobs/7598772747

Caused by:
  process didn't exit successfully: `/github/runner/_work/zkevm-circuits/zkevm-circuits/target/release/deps/testool-9af89d4775d0c804` (signal: 11, SIGSEGV: invalid memory reference)
Error: The process '/home/ubuntu/.cargo/bin/cargo' failed with exit code 101

Managed to resolve it in edc24ab
by change EvmCircuitCached to EvmCircuit。

Concrete steps to reproduce the bug

No response

[lispc]

@ed255 the Cached EvmCircuit is a bit strange..

[lispc]

oh it seems related to RUST_MIN_STACK: 16777216..

[ChihChengLiang]

RUST_MIN_STACK: 16777216 is introduced in #1286. cc @ed255

[ed255]

Ah yes, I've observed this previously. Whenever this happens signal: 11, SIGSEGV: invalid memory reference running our code, it's most likely a stack overflow. After reading some Rust documentation I found that Rust threads start with 2 MB of stack by default, and this is sometimes not enough for us. Sometimes I've encountered this issue when running the tests in the test profile instead of release profile. Recently I encountered it in release profile while developing the PR that CC linked #1286 so I added an env var to increase the stack size in github actions.
I didn't find a better way to set the default stack size other than using the env var.

My guess is that the big stack requirements comes from having the ExecutionConfig from the EVM Circuit type so big. This type is held under a Box in the EvmCircuitConfig to try to mitigate this problem. But maybe it's when this value is created that it's held in the stack and can cause the overflow.
Notice that the size of ExecutionConfig keeps growing with every execution state that we add, and with every new gadget that we add to an existing execution state.

[ed255]

I wish we could find a way to resolve the massive stack usage, so that we don't have to depend on setting a bigger stack via 16777216!

[lispc]

OK since we know the reason now and it can be resolved i think it is ok to close the issue