Closed Bug 923179 Opened 6 years ago Closed 6 years ago

GenerationalGC: jit-test asm.js/testParallelCompile.js fails in threadsafe shell builds

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla27

People

(Reporter: jonco, Assigned: jonco)

References

Details

Attachments

(1 file)

TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/asm.js/testParallelCompile.js | --no-baseline --no-ion --no-ti
TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/asm.js/testParallelCompile.js | --no-baseline --no-ion
TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/asm.js/testParallelCompile.js | 
TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/asm.js/testParallelCompile.js | --baseline-eager
TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/asm.js/testParallelCompile.js | --baseline-eager --no-ti --no-fpu
TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/asm.js/testParallelCompile.js | --ion-eager
TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/asm.js/testParallelCompile.js | --ion-eager --ion-check-range-analysis
make[1]: *** [check-jit-test] Error 2
Actually this fails in shell builds built with --enable-threadsafe.
Blocks: GenerationalGC
No longer blocks: 764882
Summary: GenerationalGC: jit-test asm.js/testParallelCompile.js fails in browser builds → GenerationalGC: jit-test asm.js/testParallelCompile.js fails in threadsafe shell builds
A heap post barrier is trying to access the store buffer during off-thread compilation, and this is causing an assertion (CurrentThreadCanAccessRuntime() is false).

Additionally, the ASM JS fault handler is then going into an infinite loop for the same reason.

Assertion failure: CurrentThreadCanAccessRuntime(rt), at ../gc/Heap.h:964
[Switching to Thread 0x7fffee7fc700 (LWP 19937)]

Catchpoint 1 (signal SIGSEGV), js::gc::Cell::runtimeFromMainThread (this=0x7ffff45620d0) at ../gc/Heap.h:964
964	../gc/Heap.h: No such file or directory.

Breakpoint 2, AsmJSFaultHandler (signum=11, info=0x7fffee7f8730, context=0x7fffee7f8600) at /home/jon/work/rooting/js/src/jit/AsmJSSignalHandlers.cpp:972
972	    if (HandleSignal(signum, info, context))
(gdb) bt
#0  AsmJSFaultHandler (signum=11, info=0x7fffee7f8730, context=0x7fffee7f8600) at /home/jon/work/rooting/js/src/jit/AsmJSSignalHandlers.cpp:972
#1  <signal handler called>
#2  js::gc::Cell::runtimeFromMainThread (this=0x7ffff45620d0) at ../gc/Heap.h:964
#3  0x0000000000461e90 in js::EncapsulatedValue::runtimeFromMainThread (v=...) at ../gc/Barrier.h:620
#4  0x0000000000461765 in js::EncapsulatedValue::shadowRuntimeFromMainThread (v=...) at ../gc/Barrier.h:627
#5  0x000000000046172f in js::HeapValue::writeBarrierPost (value=..., addr=0x7ffff4569fe0) at ../gc/Barrier.h:715
#6  0x00000000004616f3 in js::HeapValue::post (this=0x7ffff4569fe0) at ../gc/Barrier.h:730
#7  0x000000000045d25b in js::HeapValue::operator= (this=0x7ffff4569fe0, v=...) at ../gc/Barrier.h:681
#8  0x00000000004b69b0 in JSFunction::setExtendedSlot (this=(JSFunction *) 0x7ffff4569fa0 [object Function <unnamed>], which=0, val=...) at ../jsfun.h:557
#9  0x000000000096f471 in js::NewAsmJSModuleFunction (cx=0x1bba360, origFun=(JSFunction *) 0x7ffff456b940 [object Function <unnamed>], moduleObj=(JSObject * const) 0x7ffff45620d0 [object AsmJSModuleObject])
    at /home/jon/work/rooting/js/src/jit/AsmJSLink.cpp:666
#10 0x0000000000914493 in js::CompileAsmJS (cx=0x1bba360, parser=..., stmtList=0x7fffd8000a70, validated=0x7fffee7f8ed7) at /home/jon/work/rooting/js/src/jit/AsmJS.cpp:6519
#11 0x00000000005663f0 in js::frontend::Parser<js::frontend::FullParseHandler>::asmJS (this=0x7fffee7fae98, list=0x7fffd8000a70) at /home/jon/work/rooting/js/src/frontend/Parser.cpp:2534
#12 0x0000000000578fa0 in js::frontend::Parser<js::frontend::FullParseHandler>::maybeParseDirective (this=0x7fffee7fae98, list=0x7fffd8000a70, pn=0x7fffd8000ae0, cont=0x7fffee7f8faf)
    at /home/jon/work/rooting/js/src/frontend/Parser.cpp:2610
#13 0x0000000000573a09 in js::frontend::Parser<js::frontend::FullParseHandler>::statements (this=0x7fffee7fae98) at /home/jon/work/rooting/js/src/frontend/Parser.cpp:2654
Assignee: nobody → jcoppeard
IIUC, an off-main-thread ExclusiveContext is allowed to create and manipulate GC things in the ExclusiveContext's compartment and CompileAsmJS does this at the end.  Is that right?
(In reply to Luke Wagner [:luke] from comment #3)

So I don't understand all the aspects of threading in SM, but yes, according to the comments an off-main-thread ExclusiveContext can access GC things in its own compartment.  And since it's not on the main thread, it should never be able to see any nursery allocated things.

The problem here is that we're asserting we can access the main thread's runtime too soon.  It's safe for us to use the runtime to find the location of the nursery, since this is allocated once and never changes (I initially thought this got resized, but it doesn't, at least not at the moment).  And we already check we're on the right thread if it turns out we need to insert entries in the store buffer, which cannot happen if we are not on the main thread.  

So actually I think the fix is just to use runtimeFromAnyThread() rather than runtimeFromMainThread() in the appropriate places in Barrier.h.
Attachment #815421 - Flags: review?(terrence)
Comment on attachment 815421 [details] [diff] [review]
bug923179-parallelCompile

Review of attachment 815421 [details] [diff] [review]:
-----------------------------------------------------------------

Excellent! r=me
Attachment #815421 - Flags: review?(terrence) → review+
https://hg.mozilla.org/mozilla-central/rev/b49e069aeddd
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
You need to log in before you can comment on or make changes to this bug.