1513991 - Assertion failure: CurrentThreadCanAccessZone(zone), at js/src/gc/Cell.h:339 with evalInWorker and WeakMap

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P3)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision e27e7c02c708 (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --cpu-count=2 --ion-offthread-compile=off):

evalInWorker(`
var sym4 = Symbol.match;
function test(makeNonArray) {}
function basicSweeping() {}
var wm1 = new WeakMap();
wm1.set(basicSweeping, sym4);
startgc(100000, 'shrinking');
`);


Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  js::gc::TenuredCell::zone (this=<optimized out>) at js/src/gc/Cell.h:339
#1  0x000055555600c1ed in js::gc::CheckWeakMapEntryMarking (map=map@entry=0x7ffff5fa0b30, key=key@entry=0x7ffff5227140, value=0x7ffff5929050) at js/src/gc/Verifier.cpp:777
#2  0x0000555555a7af52 in js::WeakMap<js::HeapPtr<JSObject*>, js::HeapPtr<JS::Value> >::checkMarking (this=0x7ffff5fa0b30) at js/src/gc/WeakMap-inl.h:258
#3  0x000055555600b291 in js::WeakMapBase::checkMarkingForZone (zone=<optimized out>) at js/src/gc/WeakMap.cpp:55
#4  0x0000555555fa0a3b in MaybeCheckWeakMapMarking (gc=0x7ffff552c680) at js/src/gc/GC.cpp:5235
#5  js::gc::GCRuntime::endMarkingSweepGroup (this=0x7ffff552c680, fop=<optimized out>, budget=...) at js/src/gc/GC.cpp:5279
#6  0x0000555555fdbfc0 in sweepaction::SweepActionSequence<js::gc::GCRuntime*, js::FreeOp*, js::SliceBudget&>::run (this=0x7ffff5503740, args#0=0x7ffff552c680, args#1=0x7ffff68fd760, args#2=...) at js/src/gc/GC.cpp:6260
#7  0x0000555555fe131a in sweepaction::SweepActionRepeatFor<js::gc::SweepGroupsIter, JSRuntime*, js::gc::GCRuntime*, js::FreeOp*, js::SliceBudget&>::run (this=0x7ffff55d0fa0, args#0=0x7ffff552c680, args#1=0x7ffff68fd760, args#2=...) at js/src/gc/GC.cpp:6320
#8  0x0000555555f9d937 in js::gc::GCRuntime::performSweepActions (this=this@entry=0x7ffff552c680, budget=...) at js/src/gc/GC.cpp:6491
#9  0x0000555555fa8641 in js::gc::GCRuntime::incrementalSlice (this=this@entry=0x7ffff552c680, budget=..., reason=reason@entry=JS::gcreason::DEBUG_GC, session=...) at js/src/gc/GC.cpp:7007
#10 0x0000555555fa8dc2 in js::gc::GCRuntime::gcCycle (this=this@entry=0x7ffff552c680, nonincrementalByAPI=nonincrementalByAPI@entry=false, budget=..., reason=reason@entry=JS::gcreason::DEBUG_GC) at js/src/gc/GC.cpp:7353
#11 0x0000555555fa95fd in js::gc::GCRuntime::collect (this=this@entry=0x7ffff552c680, nonincrementalByAPI=nonincrementalByAPI@entry=false, budget=..., reason=reason@entry=JS::gcreason::DEBUG_GC) at js/src/gc/GC.cpp:7525
#12 0x0000555555fab205 in js::gc::GCRuntime::startDebugGC (this=this@entry=0x7ffff552c680, gckind=GC_SHRINK, budget=...) at js/src/gc/GC.cpp:7663
#13 0x0000555555c0b215 in StartGC (cx=<optimized out>, cx@entry=0x7ffff5524000, argc=<optimized out>, vp=<optimized out>) at js/src/builtin/TestingFunctions.cpp:1189
#14 0x00005555558c9571 in CallJSNative (cx=0x7ffff5524000, native=0x555555c0b170 <StartGC(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/vm/Interpreter.cpp:443
[...]
rax	0x555557b73480	93825032205440
rbx	0x7ffff5f34000	140737319747584
rcx	0x555556a797e0	93825014405088
rdx	0x0	0
rsi	0x7ffff6eeb770	140737336227696
rdi	0x7ffff6eea540	140737336223040
rbp	0x7ffff68fd450	140737330009168
rsp	0x7ffff68fd440	140737330009152
r8	0x7ffff6eeb770	140737336227696
r9	0x7ffff68ff700	140737330018048
r10	0x58	88
r11	0x7ffff6b927a0	140737332717472
r12	0x7ffff5205160	140737305923936
r13	0x7ffff5227140	140737306063168
r14	0x7ffff5fae000	140737320247296
r15	0x7ffff5929050	140737313411152
rip	0x55555599f569 <js::gc::TenuredCell::zone() const+89>
=> 0x55555599f569 <js::gc::TenuredCell::zone() const+89>:	movl   $0x0,0x0
   0x55555599f574 <js::gc::TenuredCell::zone() const+100>:	ud2



This crash looks similar to the one in bug 1507322, but the test here requires evalInWorker. Might be worth double-checking that this is the same issue. Marking s-s because this assertion can indicate s-s conditions.

Comment 1

[Fuzzing Team]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/ca4f360d2517
user:        Jon Coppeard
date:        Thu Dec 06 16:27:21 2018 -0500
summary:     Bug 1509923 - Check weak map marking state in debug builds and when enabled with a zeal mode r=sfink

This iteration took 504.916 seconds to run.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Jon, is bug 1509923 a likely regressor?

Comment 3

[Jon Coppeard (:jonco)]

Attachment: bug1513991-weak-marking-checks

It's asserting because we aren't in general access the atoms zone from a worker runtime.  However all we are doing is checking whether a zone is the atoms zone which is fine.

Comment 4

[Jon Coppeard (:jonco)]

(In reply to Jon Coppeard (:jonco) from comment #3)
Oh, and I fixed it to work for nursery strings too.  At the moment I don't think we see any nursery things at this point, but we could in the future.

Comment 5

[Andrew McCreight [:mccr8]]

This sounds like a bug in the verifier, so I'm going to unhide it.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e406499c0215
Fix weak map marking checker when accessing atoms from worker runtimes r=sfink

Comment 7

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/e406499c0215