fix(compiler): fix the remaining EVM SSA stack-lift crashes - #25
Closed
abmcar wants to merge 4 commits into
Closed
Conversation
…gate A block that is simultaneously a dynamic-jump target and a dynamic-jump source whose own JUMP net-pops the stack (entry depth != exit depth) crashed the SSA stack-lift path: getCompatibleDynamicJumpTargetBlocksForSourceBlock reused the block's target shape class as its outgoing/source class, assuming it re-dispatches at the depth it entered. For such a block that is false, so its drained (shallower) exit stack was assigned as a deeper region's entry state, tripping the EntryDepth == Values.size() assertion (silent SIGABRT in release). Gate the target-class fallback on the source block's ResolvedExitStackDepth matching the candidate shape class's entry depth (new helper getDynamicJumpShapeClassEntryDepth). This enforces the source side of the SSA-lift invariant source-exit-depth == target-entry-depth == shape-class-entry-depth, which the previous code checked only on the target side. A genuine jump-table dispatcher (entry depth == exit depth) still passes unchanged. Fixes the SIGABRT on stEIP1153_transientStorage/transStorageOK (now 48/48). Reachable only on the lift path; default (flag-off) build unaffected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… entry state When a JUMP/JUMPI terminator falls through into a JUMPDEST, the terminator handler calls handleBeginBlock for the (canonicalized) fallthrough target before the JUMPDEST opcode is decoded. The main decode loop then reaches that JUMPDEST and the JUMPDEST handler begins the same block a second time. With the SSA stack-lift path enabled this double-begin corrupts two pieces of state: 1. The JUMPDEST handler re-runs the fallthrough entry-edge assignment with CurrentBlockEntryPC == the JUMPDEST's own PC, recording a self-edge (PredBlockPC == BlockPC) that is absent from the block's predecessor order. assignStackMergeOperand then looks the predecessor up in the phi incoming-slot map, misses, and aborts (getPhiIncomingSlot ZEN_ASSERT). Reproduces on stEIP3651_warmcoinbase/coinbaseWarmAccountCallGasFail. 2. The second handleBeginBlock re-restores the lifted logical entry state onto a logical stack that the first begin already populated, doubling the stack depth. The next entry-state transfer then mismatches the successor's analyzer-computed entry depth and aborts (assignEntryState ZEN_ASSERT). Reproduces on stBadOpcode/measureGas. Both symptoms share one root cause: the block was already begun by the predecessor terminator. Detect this (RunStartPC == CurrentBlockEntryPC, gated on CurrentBlockLifted) and, instead of re-assigning the entry edge, drain the stale logical-stack copy so the re-begin below restores the lifted entry state exactly once in the canonical JUMPDEST body block. handleJumpDest still runs to wire the body branch. The guard is gated on CurrentBlockLifted, which is only set when the SSA-lift flag is enabled, so the flag-OFF decode path keeps its existing structure unchanged. Verified: EEST statetest -k fork_Cancun 2723/2723 (matches OFF baseline), multipass evmone-unittests 223/223 on a flag-OFF rebuild. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…perands getOperandIdentityKey computes a stable identity for each stack operand flowing into a lifted block's entry state. Its final branch dereferenced getU256VarComponents() whenever the Operand type exposes that accessor (an `if constexpr` compile-time check), without first confirming the operand is actually a multi-component U256 value at runtime. getU256VarComponents() asserts IsU256MultiComponent, so an operand that reached this branch while being empty/deferred (its Instr and Var accessors both returned null but it is not a constant and not multi-component) aborted the compile. Reproduces on the mainnet-replay cancun-suite fixture 0x6919aef1fbf4ed160e7e6797fbc732723c05427becdea2e72f69118e427fd832: with SSA-lift ON it hits "Not a multi-component U256" (evm_mir_compiler.h:255); with SSA-lift OFF the same fixture compiles and runs (and fails only on a pre-existing state-root mismatch shared by both builds). Add a runtime isU256MultiComponent() check before taking the var-component branch; non-multi-component operands fall through to the opaque-key path as intended. The change lives entirely inside an SSA-lift-only code path (ZEN_ENABLE_EVM_STACK_SSA_LIFT), so the flag-OFF path is unaffected. Verified: replay corpus no longer crashes and its ON/OFF failing-test sets are identical (0 regressions); EEST statetest -k fork_Cancun 2723/2723; multipass evmone-unittests 223/223 on a flag-OFF rebuild. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Owner
Author
|
Closing — a fork-internal PR is not a useful target. The follow-up will go to upstream DTVMStack/DTVM instead. |
|
✅ Performance Check Passed (interpreter) Performance Benchmark Results (threshold: 25%)
Summary: 194 benchmarks, 0 regressions |
|
✅ Performance Check Passed (multipass) Performance Benchmark Results (threshold: 25%)
Summary: 194 benchmarks, 0 regressions |
⚡ Performance Regression Check Results✅ Performance Check Passed (interpreter)Performance Benchmark Results (threshold: 25%)
Summary: 194 benchmarks, 0 regressions ✅ Performance Check Passed (multipass)Performance Benchmark Results (threshold: 25%)
Summary: 194 benchmarks, 0 regressions |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Follow-up to DTVMStack#530. Fixes the remaining crashes in the EVM multipass JIT's SSA
stack-lift path (
ZEN_ENABLE_EVM_STACK_SSA_LIFT, default OFF). After thischange, SSA-lift compiles the full EEST state-test suite and the mainnet-replay
corpus crash-free, producing results identical to the default build.
The remaining bugs
Dynamic-jump shape-class entry-depth gate — a block that is both a
dynamic-jump target and a dynamic-jump source whose own
JUMPnet-pops thestack (entry depth ≠ exit depth) had its shallow exit stack assigned as a
deeper region's entry state →
EntryDepth == Values.size()abort. Gate theshape-class fallback on the source's exit depth matching the class entry
depth (
evm_analyzer.h).JUMPDEST double-begin — when a
JUMP/JUMPIterminator falls throughinto a
JUMPDEST, both the terminator handler and the main loop begin thesame block. Benign with the flag OFF; with SSA-lift ON it adds a self-edge
PredBlockPC == BlockPC(→getPhiIncomingSlotabort) and re-restores thelifted entry state (→ depth-mismatch abort). Detect the re-begin
(
RunStartPC == CurrentBlockEntryPC, gated onCurrentBlockLifted), skip theredundant edge, and drain the stale logical-stack copy (
evm_bytecode_visitor.h).Operand identity key on a non-U256 operand —
getOperandIdentityKeydereferenced
getU256VarComponents()on a compile-time type check alone, soan empty/deferred operand hit the "Not a multi-component U256" assert. Add a
runtime
isU256MultiComponent()guard (evm_lifted_stack_lifter.h).All three are reachable only on the lift path; the default (flag-off) build is
unaffected.
Validation
evmone-unittestsevmone-statetest -k fork_Cancun(EEST)evmone-unittestsevmone-statetest -k fork_Cancuntools/format.sh checkThe lift-path EEST result matches the default-build baseline exactly.
Known residual (not a crash)
The EEST run still emits five benign
PredBlockPC == BlockPCself-edge cases onsingle-predecessor blocks (no merge phis, no abort, all tests pass). Clearing
them would need a broader audit of the terminator/JUMPDEST begin handshake
rather than a surgical change.
🤖 Generated with Claude Code