Assertion failure: CurrentThreadCanAccessRuntime(cx->runtime()), at js/src/threading/ProtectedData.cpp:65
Categories
(Core :: JavaScript: GC, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox70 | --- | unaffected |
firefox71 | --- | unaffected |
firefox72 | --- | fixed |
People
(Reporter: decoder, Assigned: allstars.chh)
References
(Regression)
Details
(4 keywords, Whiteboard: [jsbugmon:update,bisect])
Attachments
(2 files)
The following testcase crashes on mozilla-central revision 4d585c7edc76 (build with --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --ion-offthread-compile=off):
function runtest(func) {
func();
}
const g1 = newGlobal({
newCompartment: true
});
enqueueMark("enter-weak-marking-mode");
function transplantMarking() {
const vals = {};
vals.map = new WeakMap();
enqueueMark(vals.map);
enqueueMark("yield");
enqueueMark("enter-weak-marking-mode");
}
runtest(transplantMarking);
egc = 60;
gcslice(egc * 100);
x();
Backtrace:
received signal SIGSEGV, Segmentation fault.
#0 js::CheckMainThread<(js::AllowedHelperThread)0>::check (this=this@entry=0x7ffff5f2a82b) at js/src/threading/ProtectedData.cpp:65
#1 0x00005555561d7e02 in js::ProtectedData<js::CheckMainThread<(js::AllowedHelperThread)0>, bool>::ref (this=0x7ffff5f2a82a) at js/src/threading/ProtectedData.h:149
#2 js::ProtectedData<js::CheckMainThread<(js::AllowedHelperThread)0>, bool>::operator bool const& (this=0x7ffff5f2a82a) at js/src/threading/ProtectedData.h:93
#3 js::GCMarker::processMarkQueue (this=0x7ffff5f2a748) at js/src/gc/Marking.cpp:1594
#4 0x00005555561d827e in js::GCMarker::processMarkQueue (this=this@entry=0x7ffff5f2a748) at js/src/gc/Marking.cpp:1628
#5 0x000055555615788b in js::gc::GCRuntime::markUntilBudgetExhausted (this=0x7ffff5f29700, sliceBudget=...) at js/src/gc/GC.cpp:5664
#6 0x00005555561932e7 in js::gc::SweepMarkTask::run (this=0x7ffff5f2b3f0) at js/src/gc/GC.cpp:5643
#7 js::GCParallelTaskHelper<js::gc::SweepMarkTask>::runTaskTyped (task=0x7ffff5f2b3f0) at js/src/gc/GCParallelTask.h:202
#8 0x0000555555b9ef45 in js::GCParallelTask::runTask (this=0x7ffff5f2b3f0) at js/src/vm/HelperThreads.cpp:1833
#9 0x0000555555ba5a2a in js::GCParallelTask::runFromHelperThread (this=0x7ffff5f2b3f0, lock=...) at js/src/vm/HelperThreads.cpp:1818
#10 0x0000555555ba986c in js::HelperThread::handleGCParallelWorkload (this=0x7ffff5f07c48, lock=...) at js/src/vm/HelperThreads.cpp:1855
#11 0x0000555555ba36d4 in js::HelperThread::threadLoop (this=0x7ffff5f07c48) at js/src/vm/HelperThreads.cpp:2656
#12 0x0000555555bd35f7 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul> (this=<optimized out>) at js/src/threading/Thread.h:210
#13 js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start (aPack=0x7ffff5f26120) at js/src/threading/Thread.h:199
#14 0x00007ffff7bc16ba in start_thread (arg=0x7ffff5d01700) at pthread_create.c:333
#15 0x00007ffff6c2c41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
rax 0x5555580adfa0 93825037688736
rbx 0x7ffff5f2a748 140737319708488
rcx 0x555556ec0880 93825018890368
rdx 0x0 0
rsi 0x7ffff6eeb770 140737336227696
rdi 0x7ffff6eea540 140737336223040
rbp 0x7ffff5d00630 140737317439024
rsp 0x7ffff5d00630 140737317439024
r8 0x7ffff6eeb770 140737336227696
r9 0x7ffff5d01700 140737317443328
r10 0x0 0
r11 0x0 0
r12 0x7ffff5d006a0 140737317439136
r13 0x7ffff5f29000 140737319702528
r14 0x7ffff5d006c6 140737317439174
r15 0x7ffff5f2a84a 140737319708746
rip 0x555555af5029 <js::CheckMainThread<(js::AllowedHelperThread)0>::check() const+89>
=> 0x555555af5029 <js::CheckMainThread<(js::AllowedHelperThread)0>::check() const+89>: movl $0x0,0x0
0x555555af5034 <js::CheckMainThread<(js::AllowedHelperThread)0>::check() const+100>: ud2
This issue is somewhat intermittent, but the test provided here worked reliably for me.
Reporter | ||
Comment 1•5 years ago
|
||
This looks similar to bug 1592487, so maybe Yoshi is a good start. Not sure if the bisection for this one will be accurate due to intermittency.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
Thanks for filing this.
I will fix this.
I have one question though, the test script will throw Reference Error, is this intended?
(In reply to Christian Holler (:decoder) from comment #0)
function runtest(func) { func(); } const g1 = newGlobal({ newCompartment: true }); enqueueMark("enter-weak-marking-mode"); function transplantMarking() { const vals = {}; vals.map = new WeakMap(); enqueueMark(vals.map); enqueueMark("yield"); enqueueMark("enter-weak-marking-mode"); } runtest(transplantMarking); egc = 60; gcslice(egc * 100); x();
ReferenceError: x is not defined
thanks
Reporter | ||
Comment 3•5 years ago
|
||
Yes, that's intended. I was not able to remove this part, it seems to be required to reproduce (I suspect some kind of thread race / timing issue).
Assignee | ||
Comment 4•5 years ago
|
||
Assignee | ||
Comment 5•5 years ago
|
||
The ReferenceError will make the test fail even I fixed the assertion, so I add a try-catch to wrap the x() call.
Pushed by allstars.chh@gmail.com: https://hg.mozilla.org/integration/autoland/rev/6922ef47c257 update linearWeakMarkingDisabled_ to MainThreadOrGCTaskData. r=jonco
Comment 7•5 years ago
|
||
Backed out changeset 6922ef47c257 (Bug 1593975) for sm bustages on bug-1593975.js.
Backout: https://hg.mozilla.org/integration/autoland/rev/af59b0e5851cfa43f709449bd2b0cb4950424640
Push that started the failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&revision=6922ef47c25721aa5e7bc2a7bed57161a8b0f21e&selectedJob=274706047
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=274706047&repo=autoland&lineNumber=27969
Comment 8•5 years ago
|
||
(In reply to Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh] from comment #5)
The ReferenceError will make the test fail even I fixed the assertion, so I add a try-catch to wrap the x() call.
You can tell the test harness to expect an error, for example: https://searchfox.org/mozilla-central/source/js/src/jit-test/tests/TypedObject/fuzz9.js#1
Assignee | ||
Comment 9•5 years ago
|
||
check if enqueueMark is defined in opt build, and tell harness a ReferenceError
is expected.
Assignee | ||
Comment 10•5 years ago
|
||
(In reply to Cristian Brindusan [:cbrindusan] from comment #7)
Backed out changeset 6922ef47c257 (Bug 1593975) for sm bustages on bug-1593975.js.
Backout: https://hg.mozilla.org/integration/autoland/rev/af59b0e5851cfa43f709449bd2b0cb4950424640
Push that started the failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&revision=6922ef47c25721aa5e7bc2a7bed57161a8b0f21e&selectedJob=274706047
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=274706047&repo=autoland&lineNumber=27969
Just noticed enqueueMark is only defined in DEBUG build, so update the test in another patch.
(In reply to Jon Coppeard (:jonco) from comment #8)
The ReferenceError will make the test fail even I fixed the assertion, so I add a try-catch to wrap the x() call.
You can tell the test harness to expect an error, for example: https://searchfox.org/mozilla-central/source/js/src/jit-test/tests/TypedObject/fuzz9.js#1
Thanks for the tips, Jonco. I also addressed this in the test.
Updated•5 years ago
|
Comment 11•5 years ago
|
||
Pushed by allstars.chh@gmail.com: https://hg.mozilla.org/integration/autoland/rev/9d6c5b6e3275 update linearWeakMarkingDisabled_ to MainThreadOrGCTaskData. r=jonco
Comment 12•5 years ago
|
||
Pushed by allstars.chh@gmail.com: https://hg.mozilla.org/integration/autoland/rev/bec112cfa8d2 update test. r=jonco
Comment 13•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/9d6c5b6e3275
https://hg.mozilla.org/mozilla-central/rev/bec112cfa8d2
Updated•5 years ago
|
Updated•2 years ago
|
Description
•