1515993 - Assertion failure: WeakMapBase::checkMarkingForZone(zone), at js/src/gc/GC.cpp:5280 with Debugger

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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

function checkGetOffsetsCoverage(fun) {
    var source = fun.toSource();
    source = source.slice(source.indexOf('{') + 1, source.lastIndexOf('}'));
    var g = newGlobal();
    var dbg = Debugger(g);
    var topLevel = null;
    dbg.onNewScript = function(s) {
        topLevel = s;
    };
    g.eval(source);
    function collectCoverage(s) {
        s.getChildScripts().forEach(collectCoverage);
    };
    collectCoverage(topLevel);
}
checkGetOffsetsCoverage(function() {
    switch (import((yield) => next / l.BYTES_PER_ELEMENT).length) {}
});
gczeal(14, 10);
Object.defineProperty(this, "fuzzutils", {});


Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  MaybeCheckWeakMapMarking (gc=0x7ffff5f1c680) at js/src/gc/GC.cpp:5280
#1  js::gc::GCRuntime::endMarkingSweepGroup (this=0x7ffff5f1c680, fop=<optimized out>, budget=...) at js/src/gc/GC.cpp:5350
#2  0x0000555555ffd9b0 in sweepaction::SweepActionSequence<js::gc::GCRuntime*, js::FreeOp*, js::SliceBudget&>::run (this=0x7ffff5f173d0, args#0=0x7ffff5f1c680, args#1=0x7fffffffbd10, args#2=...) at js/src/gc/GC.cpp:6336
#3  0x0000555555fff74a in sweepaction::SweepActionRepeatFor<js::gc::SweepGroupsIter, JSRuntime*, js::gc::GCRuntime*, js::FreeOp*, js::SliceBudget&>::run (this=0x7ffff5f191f0, args#0=0x7ffff5f1c680, args#1=0x7fffffffbd10, args#2=...) at js/src/gc/GC.cpp:6396
#4  0x0000555555fbeb97 in js::gc::GCRuntime::performSweepActions (this=this@entry=0x7ffff5f1c680, budget=...) at js/src/gc/GC.cpp:6568
#5  0x0000555555fc872c in js::gc::GCRuntime::incrementalSlice (this=this@entry=0x7ffff5f1c680, budget=..., reason=reason@entry=JS::gcreason::DEBUG_GC, session=...) at js/src/gc/GC.cpp:7084
#6  0x0000555555fc9012 in js::gc::GCRuntime::gcCycle (this=this@entry=0x7ffff5f1c680, nonincrementalByAPI=nonincrementalByAPI@entry=true, budget=..., reason=reason@entry=JS::gcreason::DEBUG_GC) at js/src/gc/GC.cpp:7429
#7  0x0000555555fc984d in js::gc::GCRuntime::collect (this=this@entry=0x7ffff5f1c680, nonincrementalByAPI=nonincrementalByAPI@entry=true, budget=..., reason=reason@entry=JS::gcreason::DEBUG_GC) at js/src/gc/GC.cpp:7601
#8  0x0000555555fc9c59 in js::gc::GCRuntime::gc (this=this@entry=0x7ffff5f1c680, gckind=gckind@entry=GC_SHRINK, reason=reason@entry=JS::gcreason::DEBUG_GC) at js/src/gc/GC.cpp:7679
#9  0x0000555555fcb799 in js::gc::GCRuntime::runDebugGC (this=this@entry=0x7ffff5f1c680) at js/src/gc/GC.cpp:8198
#10 0x0000555555fcb8be in js::gc::GCRuntime::gcIfNeededAtAllocation (this=this@entry=0x7ffff5f1c680, cx=cx@entry=0x7ffff5f18000) at js/src/gc/Allocator.cpp:338
#11 0x00005555560001c8 in js::gc::GCRuntime::checkAllocatorState<(js::AllowGC)1> (this=this@entry=0x7ffff5f1c680, cx=cx@entry=0x7ffff5f18000, kind=kind@entry=js::gc::AllocKind::FUNCTION) at js/src/gc/Allocator.cpp:302
#12 0x00005555560003ff in js::Allocate<JSObject, (js::AllowGC)1> (cx=cx@entry=0x7ffff5f18000, kind=kind@entry=js::gc::AllocKind::FUNCTION, nDynamicSlots=nDynamicSlots@entry=0, heap=heap@entry=js::gc::TenuredHeap, clasp=clasp@entry=0x555557b339e0 <JSFunction::class_>) at js/src/gc/Allocator.cpp:56
#13 0x0000555555b4b1de in JSFunction::create (cx=0x7ffff5f18000, kind=<optimized out>, heap=js::gc::TenuredHeap, shape=..., group=...) at js/src/vm/JSFunction-inl.h:112
#14 0x0000555555b0f2f9 in NewObject (cx=<optimized out>, group=..., kind=<optimized out>, newKind=js::SingletonObject, initialShapeFlags=<optimized out>) at js/src/vm/JSObject.cpp:796
#15 0x0000555555b0fc0e in js::NewObjectWithClassProtoCommon (cx=<optimized out>, clasp=clasp@entry=0x555557b339e0 <JSFunction::class_>, protoArg=..., protoArg@entry=..., allocKind=allocKind@entry=js::gc::AllocKind::FUNCTION, newKind=newKind@entry=js::SingletonObject) at js/src/vm/JSObject.cpp:931
#16 0x0000555555adb1cd in js::NewObjectWithClassProto (newKind=js::SingletonObject, allocKind=js::gc::AllocKind::FUNCTION, proto=..., clasp=0x555557b339e0 <JSFunction::class_>, cx=<optimized out>) at js/src/vm/JSObject-inl.h:487
#17 js::NewObjectWithClassProto<JSFunction> (newKind=js::SingletonObject, allocKind=js::gc::AllocKind::FUNCTION, proto=..., cx=<optimized out>) at js/src/vm/JSObject-inl.h:509
#18 NewFunctionClone (cx=<optimized out>, cx@entry=0x7ffff5f18000, fun=fun@entry=..., newKind=newKind@entry=js::SingletonObject, allocKind=allocKind@entry=js::gc::AllocKind::FUNCTION, proto=...) at js/src/vm/JSFunction.cpp:2247
#19 0x0000555555adb912 in js::CloneSelfHostingIntrinsic (cx=0x7ffff5f18000, fun=fun@entry=...) at js/src/vm/JSFunction.cpp:2410
#20 0x0000555555bee7b7 in CloneObject (cx=<optimized out>, cx@entry=0x7ffff5f18000, selfHostedObject=selfHostedObject@entry=...) at js/src/vm/SelfHosting.cpp:3195
#21 0x0000555555bf03d7 in CloneValue (cx=cx@entry=0x7ffff5f18000, selfHostedValue=..., selfHostedValue@entry=..., vp=...) at js/src/vm/SelfHosting.cpp:3244
#22 0x0000555555bf06d3 in JSRuntime::cloneSelfHostedValue (this=0x7ffff5f1c000, cx=cx@entry=0x7ffff5f18000, name=..., name@entry=..., vp=...) at js/src/vm/SelfHosting.cpp:3383
#23 0x00005555558c792e in js::GlobalObject::getIntrinsicValue (value=..., name=..., global=..., cx=0x7ffff5f18000) at js/src/vm/GlobalObject.h:785
#24 js::GetIntrinsicOperation (cx=<optimized out>, script=..., pc=<optimized out>, vp=...) at js/src/vm/Interpreter-inl.h:293
#25 0x00005555558b0a11 in Interpret (cx=0x7ffff5f18000, state=...) at js/src/vm/Interpreter.cpp:3494
[...]
#35 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at js/src/shell/js.cpp:11107
rax	0x555557bb3480	93825032467584
rbx	0x7ffff5f1d648	140737319654984
rcx	0x555556b59980	93825015323008
rdx	0x0	0
rsi	0x7ffff6eeb770	140737336227696
rdi	0x7ffff6eea540	140737336223040
rbp	0x7fffffffbbe0	140737488337888
rsp	0x7fffffffbb60	140737488337760
r8	0x7ffff6eeb770	140737336227696
r9	0x7ffff7fe6cc0	140737354034368
r10	0x58	88
r11	0x7ffff6b927a0	140737332717472
r12	0x7ffff5f1c680	140737319650944
r13	0x7fffffffbb60	140737488337760
r14	0x7ffff5f1c700	140737319651072
r15	0x0	0
rip	0x555555fbef7c <js::gc::GCRuntime::endMarkingSweepGroup(js::FreeOp*, js::SliceBudget&)+444>
=> 0x555555fbef7c <js::gc::GCRuntime::endMarkingSweepGroup(js::FreeOp*, js::SliceBudget&)+444>:	movl   $0x0,0x0
   0x555555fbef87 <js::gc::GCRuntime::endMarkingSweepGroup(js::FreeOp*, js::SliceBudget&)+455>:	ud2


This could be shell-only and/or Debugger-only. Marking s-s until investigated because it is a GC assert.

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/1aefa97ae116
user:        Jon Coppeard
date:        Thu Dec 06 16:27:22 2018 -0500
summary:     Bug 1463462 - Make weak map marking take account of the fact that black and gray marking can now be interleaved r=sfink

This iteration took 516.829 seconds to run.

Comment 2

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

Jon, is bug 1463462 a likely regressor?

Comment 3

[Jon Coppeard (:jonco)]

Attachment: bug1515993-weak-map-marking

The problem is that we end up marking a weak map entry during gray marking when both the key and the map are black.  This should have happened during black marking.

On further investigation it turned out that we don't implement linear time weak map marking for LazyScripts.  I think this is a bug, since these are used as weak map keys by the debugger.

This is probably debugger only.

Comment 4

[Andrew McCreight [:mccr8]]

Marking sec-moderate due to being debugger only.

Comment 5

[Steve Fink [:sfink] [:s:]]

Comment on attachment 9033781 [details] [diff] [review]
bug1515993-weak-map-marking

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

Oh, weird. Yes, the intent was that LazyScript* is also a valid key type, and it's handled in other places.

I probably also fixed this in my (unlanded) patch over in bug 1507322.

Comment 6

[Jon Coppeard (:jonco)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/93bc74cb72cfcf00b16eea08baa9187c3375e74d

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/93bc74cb72cf

Comment 8

[Fuzzing Team]

JSBugMon: This bug has been automatically verified fixed.