This fixes a crash / potential corruption in JavaScriptCore’s JIT direct-eval operations that failed to update the VM’s top call frame. operationCallDirectEvalSloppy/Strict (and the …TaintedByWithScope variants) run when a direct eval() is invoked from JIT code. They derive the VM from the caller frame because the callee frame may be garbage at entry. Pre-patch they computed VM& vm = calleeFrame->callerFrame()->deprecatedVM() but did NOT install a JITOperationPrologueCallFrameTracer, so the VM’s current top call frame was left pointing at the untrusted callee/garbage frame during the operation. If the operation subsequently allocates or throws — for example eval of an enormous string that triggers an out-of-memory or exception, as the regression test does — the engine walks the stack or runs GC using that stale/garbage top frame, causing a crash (and potentially memory corruption).

The fix captures CallFrame* callFrame = calleeFrame->callerFrame() and constructs JITOperationPrologueCallFrameTracer tracer(vm, callFrame), setting the VM’s top call frame to the trusted caller for the duration of the operation.

The restored invariant is that JIT runtime operations that can allocate or throw set the correct top call frame via the tracer. The test evals huge strings in a loop to force the allocation/throw path.

A crash and potential memory corruption in the WebContent process, reachable by calling eval() from JIT-compiled code and forcing an allocation/throw. The advisory rates it a crash; the missing top-frame update is the kind of engine-state inconsistency that can be developed into stronger primitives.