← All issues

[25] [JSC] Don't advance bytecode when reifying inline frames at a checkpoint

Severity: Medium | Component: JSC DFG JIT | 4e802a1

Rated Medium because the diff fixes incorrect exception-handler dispatch metadata: the CallSiteIndex written into reified baseline frames during OSR exit was the bytecode AFTER the checkpoint, so a throw from the re-executed checkpoint instruction matched the wrong HandlerInfo try-range.

reifyInlinedCallFrames used bytecodeIndexForExit(...) which normalizes a checkpoint-bearing index to the bytecode position after the checkpoint — correct for resumption (kept in a separate sidestate), wrong for unwinding.

Source/JavaScriptCore/dfg/DFGOSRExitCompilerCommon.cpp

- BytecodeIndex exitIndex = baselineCodeBlock->bytecodeIndexForExit(codeOrigin->bytecodeIndex());
+ BytecodeIndex exitIndex(codeOrigin->bytecodeIndex().offset());

Off-by-one between the bytecode-index used for resumption and the bytecode-index used for exception-handler lookup when reifying inlined frames at a checkpoint.

🔒

How an off-by-one in a JIT bookkeeping helper rewrites the JavaScript exception-handling contract, and how far that semantic divergence might be pushed.

Subscribe to read more

🔒

Three reusable patterns for finding similar checkpoint/index-normalization mismatches across JSC's OSR exit, unwind, and inline-cache paths.

Subscribe to read more