1269759 - Assertion failure: rt->gc.nursery.isEmpty(), at js/src/jsgcinlines.h:198 or Assertion failure: zone->runtimeFromAnyThread()->gc.nursery.isEmpty(), at js/src/jsgcinlines.h:197 with OOM

Status: RESOLVED DUPLICATE of bug 1271110

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 77cead2cd203 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --fuzzing-safe --thread-count=2 --ion-extra-checks --ion-offthread-compile=off --ion-check-range-analysis --baseline-eager):

lfLogBuffer = `
//selectmode 4
gcslice(1000000);
gczeal(10, 0);
`.split('\n')
var lfCodeBuffer
while (true) {
    line = lfLogBuffer.shift()
    lfCodeBuffer += line + "\n"
    loadFile(lfCodeBuffer)
    function loadFile(lfVarx) {
        oomTest(function() {
            m = parseModule(lfVarx)
            m.declarationInstantiation()
            m.evaluation()
        })
    }
}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x000000000090f641 in ZoneCellIterImpl (kind=js::gc::OBJECT_LIMIT, zone=0x7ffff698a000, this=0x7fffffffb118) at js/src/jsgcinlines.h:198
#0  0x000000000090f641 in ZoneCellIterImpl (kind=js::gc::OBJECT_LIMIT, zone=0x7ffff698a000, this=0x7fffffffb118) at js/src/jsgcinlines.h:198
#1  emplace<JS::Zone*&, js::gc::AllocKind&> (this=0x7fffffffb110) at js/src/debug64/dist/include/mozilla/Maybe.h:386
#2  js::gc::ZoneCellIter::ZoneCellIter (this=0x7fffffffb110, zone=0x7ffff698a000, kind=js::gc::OBJECT_LIMIT) at js/src/jsgcinlines.h:266
#3  0x0000000000c8fbdc in JS::Zone::discardJitCode (this=0x7ffff698a000, fop=0x7ffff6956b20) at js/src/gc/Zone.cpp:210
#4  0x0000000000b95f14 in js::AutoClearTypeInferenceStateOnOOM::~AutoClearTypeInferenceStateOnOOM (this=0x7fffffffb268, __in_chrg=<optimized out>) at js/src/vm/TypeInference.cpp:4440
#5  0x000000000070e063 in js::AutoEnterAnalysis::~AutoEnterAnalysis (this=<optimized out>, __in_chrg=<optimized out>) at js/src/vm/TypeInference-inl.h:307
#6  0x0000000000b9b0cb in js::TypeMonitorResult (cx=cx@entry=0x7ffff6908c00, script=script@entry=0x7ffff7e78bf0, pc=pc@entry=0x7ffff693c087 ":", type=...) at js/src/vm/TypeInference.cpp:3252
#7  0x0000000000b9b19e in js::TypeMonitorResult (cx=cx@entry=0x7ffff6908c00, script=0x7ffff7e78bf0, pc=pc@entry=0x7ffff693c087 ":", rval=...) at js/src/vm/TypeInference.cpp:3265
#8  0x00000000007e4354 in Monitor (rval=..., pc=<optimized out>, script=<optimized out>, cx=0x7ffff6908c00) at js/src/vm/TypeInference-inl.h:552
#9  js::jit::DoTypeMonitorFallback (cx=0x7ffff6908c00, payload=<optimized out>, stub=0x7ffff4755690, value=..., res=...) at js/src/jit/SharedIC.cpp:4226
#10 0x00007ffff7febeeb in ?? ()
[...]
#44 0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x7fffffffb110	140737488335120
rcx	0x7ffff6ca588d	140737333844109
rdx	0x0	0
rsi	0x7ffff6f7a9d0	140737336814032
rdi	0x7ffff6f791c0	140737336807872
rbp	0x7fffffffb100	140737488335104
rsp	0x7fffffffb0c0	140737488335040
r8	0x7ffff7fdf7c0	140737354004416
r9	0x6372732f736a2f6c	7165916604736876396
r10	0x7fffffffae80	140737488334464
r11	0x7ffff6c27ee0	140737333329632
r12	0x7ffff698a000	140737330585600
r13	0x7ffff6953000	140737330360320
r14	0xe	14
r15	0x7ffff6953000	140737330360320
rip	0x90f641 <js::gc::ZoneCellIter::ZoneCellIter(JS::Zone*, js::gc::AllocKind)+833>
=> 0x90f641 <js::gc::ZoneCellIter::ZoneCellIter(JS::Zone*, js::gc::AllocKind)+833>:	movl   $0xc6,0x0
   0x90f64c <js::gc::ZoneCellIter::ZoneCellIter(JS::Zone*, js::gc::AllocKind)+844>:	callq  0x4b07b0 <abort()>


This bug often leads to unreproducible test cases, this one seems to work reliably though. Would be helpful to fix this while it can still be reproduced well.

Comment 1

[Fuzzing Team]

JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20160413065052" and the hash "4b36ba6198154815e958ebeb1e08ce631e36bbb6".
The "bad" changeset has the timestamp "20160413070636" and the hash "5d944b43c2173abb3426503ced62074ba739e112".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4b36ba6198154815e958ebeb1e08ce631e36bbb6&tochange=5d944b43c2173abb3426503ced62074ba739e112

Comment 2

[Fuzzing Team]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 0177462aac74).

Comment 3

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

This probably became intermittent again. Not sure if Hannes' patch tickled it as per comment 1.

Comment 4

[Hannes Verschore [:h4writer]]

Not sure my expertise. Forwarding to terrence to take a look.
The patches in the "regression" range add some more alloc return checks, but with a quick look I don't see how this could perturbed the nursery emptiness.

Comment 5

[Terrence Cole [:terrence]]

I was not able to reproduce, but it's a known signature.

Jon, you were looking at these recently, I think?

Comment 6

[Jon Coppeard (:jonco)]

Yes, it's the same issue as bug 1271110.