Assertion failure: !gc::IsAboutToBeFinalized(&r.front().value()), at js/src/jsweakmap.h:368

RESOLVED FIXED in Firefox 43

Status

()

--
critical
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: decoder, Assigned: sfink)

Tracking

(Blocks: 2 bugs, {assertion, regression, testcase})

Trunk
mozilla43
x86_64
Linux
assertion, regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox43 fixed)

Details

(Whiteboard: [jsbugmon:update,bisect])

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
The following testcase crashes on mozilla-central revision 90d9b7c391d3 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --fuzzing-safe --thread-count=2):

var lfcode = new Array();
lfcode.push = loadFile;
lfcode.push("");
lfcode.push("setInterruptCallback(function() {});");
lfcode.push("");
lfcode.push("");
lfcode.push("enableShellObjectMetadataCallback(function(r, ...d) {});");
lfcode.push("");
lfcode.push("");
lfcode.push("");
lfcode.push("");
lfcode.push("");
lfcode.push(`
    var s = "a";
    last = s[oomAfterAllocations(1)];
`);
function loadFile(lfVarx) {
  function newFunc(x) {
      new Function(x)();
  };
  newFunc(lfVarx);
}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000c13427 in js::WeakMap<js::PreBarriered<JSObject*>, js::RelocatablePtr<JS::Value>, js::DefaultHasher<js::PreBarriered<JSObject*> > >::assertEntriesNotAboutToBeFinalized (this=this@entry=0x7ffff6903580) at js/src/jsweakmap.h:368
#0  0x0000000000c13427 in js::WeakMap<js::PreBarriered<JSObject*>, js::RelocatablePtr<JS::Value>, js::DefaultHasher<js::PreBarriered<JSObject*> > >::assertEntriesNotAboutToBeFinalized (this=this@entry=0x7ffff6903580) at js/src/jsweakmap.h:368
#1  0x0000000000c1412c in js::WeakMap<js::PreBarriered<JSObject*>, js::RelocatablePtr<JS::Value>, js::DefaultHasher<js::PreBarriered<JSObject*> > >::sweep (this=0x7ffff6903580) at js/src/jsweakmap.h:337
#2  0x0000000000be4f1b in js::WeakMapBase::sweepCompartment (c=0x7ffff6956000) at js/src/jsweakmap.cpp:123
#3  0x0000000000ad524a in JSCompartment::sweepWeakMaps (this=<optimized out>) at js/src/jscompartment.cpp:650
#4  0x0000000000b95016 in js::gc::GCRuntime::beginSweepingZoneGroup (this=this@entry=0x7ffff693c408) at js/src/jsgc.cpp:5001
#5  0x0000000000b96411 in js::gc::GCRuntime::beginSweepPhase (this=this@entry=0x7ffff693c408, destroyingRuntime=destroyingRuntime@entry=false) at js/src/jsgc.cpp:5174
#6  0x0000000000b9b25b in js::gc::GCRuntime::incrementalCollectSlice (this=this@entry=0x7ffff693c408, budget=..., reason=reason@entry=JS::gcreason::DESTROY_CONTEXT) at js/src/jsgc.cpp:5913
#7  0x0000000000b9c192 in js::gc::GCRuntime::gcCycle (this=this@entry=0x7ffff693c408, incremental=incremental@entry=false, budget=..., reason=reason@entry=JS::gcreason::DESTROY_CONTEXT) at js/src/jsgc.cpp:6110
#8  0x0000000000b9c512 in js::gc::GCRuntime::collect (this=this@entry=0x7ffff693c408, incremental=incremental@entry=false, budget=..., reason=reason@entry=JS::gcreason::DESTROY_CONTEXT) at js/src/jsgc.cpp:6239
#9  0x0000000000b9c830 in js::gc::GCRuntime::gc (this=this@entry=0x7ffff693c408, gckind=gckind@entry=GC_NORMAL, reason=reason@entry=JS::gcreason::DESTROY_CONTEXT) at js/src/jsgc.cpp:6300
#10 0x0000000000ada785 in js::DestroyContext (cx=0x7ffff6907000, mode=js::DCM_FORCE_GC) at js/src/jscntxt.cpp:186
#11 0x0000000000ada9fe in JS_DestroyContext (cx=<optimized out>) at js/src/jsapi.cpp:792
#12 0x00000000004781b9 in DestroyContext (withGC=true, cx=0x7ffff6907000) at js/src/shell/js.cpp:5597
#13 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at js/src/shell/js.cpp:6405
rax	0x0	0
rbx	0x7fffffffce20	140737488342560
rcx	0x7ffff6ca53cd	140737333842893
rdx	0x0	0
rsi	0x7ffff6f7a9d0	140737336814032
rdi	0x7ffff6f791c0	140737336807872
rbp	0x7fffffffce60	140737488342624
rsp	0x7fffffffce10	140737488342544
r8	0x7ffff7fe0780	140737354008448
r9	0x6372732f736a2f6c	7165916604736876396
r10	0x7ffff6f76be0	140737336798176
r11	0x0	0
r12	0x7fffffffce10	140737488342544
r13	0x7ffff69035a8	140737330034088
r14	0x7ffff695a5d0	140737330390480
r15	0x7fffffffcf30	140737488342832
rip	0xc13427 <js::WeakMap<js::PreBarriered<JSObject*>, js::RelocatablePtr<JS::Value>, js::DefaultHasher<js::PreBarriered<JSObject*> > >::assertEntriesNotAboutToBeFinalized()+311>
=> 0xc13427 <js::WeakMap<js::PreBarriered<JSObject*>, js::RelocatablePtr<JS::Value>, js::DefaultHasher<js::PreBarriered<JSObject*> > >::assertEntriesNotAboutToBeFinalized()+311>:	movl   $0x170,0x0
   0xc13432 <js::WeakMap<js::PreBarriered<JSObject*>, js::RelocatablePtr<JS::Value>, js::DefaultHasher<js::PreBarriered<JSObject*> > >::assertEntriesNotAboutToBeFinalized()+322>:	callq  0x499bc0 <abort()>
I guess this is probably related to the recent changes in weakmap marking.
Flags: needinfo?(sphink)
(Assignee)

Comment 2

3 years ago
Yes, totally me. I guess I should have given decoder a new version of that patch to fuzz before landing, instead of just fixing the one bug he found. :-(
Assignee: nobody → sphink
Flags: needinfo?(sphink)
(Assignee)

Comment 3

3 years ago
Created attachment 8650556 [details] [diff] [review]
check the actual current marking mode instead of the permanent intention

The problem is that when deciding whether to fall back to iterative marking, I was looking at where the (permanent) tag was ExpandWeakmaps, which doesn't handle the case where weak marking mode was aborted. Instead, I say that we can only skip iterative marking of weakmaps when we are actually doing the magic weak marking dance. This is overly conservative, since markers that unconditionally mark all or no weakmap keys don't need to iterate, but this best matches the behavior from before my change and so seems safest.

Fuzzers are awesome.
Attachment #8650556 - Flags: review?(terrence)
Comment on attachment 8650556 [details] [diff] [review]
check the actual current marking mode instead of the permanent intention

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

Do we have any mechanism for the fuzzers to easily force the fallback path?
Attachment #8650556 - Flags: review?(terrence) → review+
https://hg.mozilla.org/mozilla-central/rev/c09feddabbc9
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox43: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
You need to log in before you can comment on or make changes to this bug.