Closed Bug 1137465 Opened 5 years ago Closed 5 years ago
Intermittent SM(ggc) shell/futex
.js | (args: "") | (TIMEOUT)
TEST-UNEXPECTED-FAIL | shell/futex.js | (args: "") | (TIMEOUT) make: *** [check-jstests] Error 1 make: Leaving directory `/builds/slave/m-in_l64-d_sm-ggc-000000000000/src/obj-spider/js/src' make: *** [check-jstests] Error 2
Debug log with setting `DEBUG = true` in shell/futex.js > ## shell/futex.js: rc = -9, run time = 150.003500 > Sleeping for 3 seconds > Waking the main thread now > Woke up as I should have in 3.052s > Starting outer wait > In the interrupt, starting inner wait > Script runs for too long, terminating.
Possibly related: https://github.com/lars-t-hansen/parlib-simple/issues/26 Starting to look like a lost wakeup.
The code in JSRuntime::requestInterrupt() is /mildly/ implicated in the following way: if I modify it so that it either calls fx.wake() (if a futex is waiting) /or/ InterruptRunningJitCode() (otherwise) I can no longer (or not yet, and not for lack of trying) provoke an error (see below). If it calls both of those then the error is not so hard to provoke. The error in this case is the one described in the bug linked from comment #4, namely, the iterated mandelbrot animation with SIMD after a while (not always, but often) comes to a halt, with all workers sitting in futexWait and the main thread sitting in its event loop waiting for something to happen, ie, a wakeup has been lost. Now, doing one or the other thing but not both may not be correct, so I don't think that's a fix, and there's probably a deeper reason why a wakeup gets lost here, if that's indeed what is happening.
[Mass Closure] Closing bug as the WORKSFORME as the intermittent failure has not been seen for 45+ days If this has been closed and you feel that it should Not have been closed, please reopen and add [leave open] to the whiteboard.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.