Bug 239457 – The VMTraps signal handler should no return SignalAction::NotHandled on codeBlockSet lock contention.

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Mark Lam]

The signal handler is triggered by the mutator thread due to the installed halt instructions in JIT code (which we already confirmed higher up in the signal handler). Hence, the mutator cannot be in C++ code, and therefore, cannot be already holding the codeBlockSet lock.   The only time the codeBlockSet lock could be in contention is if the Sampling Profiler thread is holding it.  In that case, we'll simply wait till the Sampling Profiler is done with it.  There are no lock ordering issues w.r.t. the Sampling Profiler on this code path.

Note that it is not ok to return SignalAction::NotHandled here if we see contention.  Doing so will cause the fault to be handled by the default handler, which will crash.  It is also not productive to return SignalAction::Handled on contention.  Doing so will simply trigger this fault handler over and over again.  We might as well wait for the Sampling Profiler to release the lock, which is what we should do.

This issue was detected by the stress/get-array-length-concurrently-change-mode.js.ftl-no-cjit-validate-sampling-profiler test, resulting in intermittent crashes.

[Mark Lam]

Created attachment 457813 [details]
[fast-cq] proposed patch.

[Radar WebKit Bug Importer]

<rdar://problem/91908204>

[Yusuke Suzuki]

Comment on attachment 457813 [details]
[fast-cq] proposed patch.

r=me

[Mark Lam]

Comment on attachment 457813 [details]
[fast-cq] proposed patch.

Thanks for the review.

[EWS]

Committed r292978 (249741@main): <https://commits.webkit.org/249741@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 457813 [details].