Closed Bug 1593975 Opened 5 years ago Closed 5 years ago

Assertion failure: CurrentThreadCanAccessRuntime(cx->runtime()), at js/src/threading/ProtectedData.cpp:65

Categories

(Core :: JavaScript: GC, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla72
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.

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.

Flags: needinfo?(allstars.chh)
Assignee: nobody → allstars.chh
Flags: needinfo?(allstars.chh)

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

Regressed by: 1564136

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).

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

(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

check if enqueueMark is defined in opt build, and tell harness a ReferenceError
is expected.

(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.

Flags: needinfo?(allstars.chh)
Attachment #9106877 - Attachment description: Bug 1593975 - update test. r? jonco → Bug 1593975 - update test.
Pushed by allstars.chh@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/9d6c5b6e3275
update linearWeakMarkingDisabled_ to MainThreadOrGCTaskData. r=jonco
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: