1211913 - Assertion failure: !hasUncompiledScript(), at js/src/shell/../jsfun.h:422

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central-oom (https://github.com/nbp/gecko-dev/tree/oom) revision c119c16978b4f08f5e0c1269b52b9fdd9085be5f (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --fuzzing-safe --thread-count=2 --ion-check-range-analysis --ion-eager --baseline-eager --ion-extra-checks):

const verbose = false;
if (!("oomAtAllocation" in this && "resetOOMFailure" in this))
    quit();
if ("gczeal" in this)
    gczeal(0);
function oomTest(f) {
    var i = 1;
    var more;
    do {
        if (verbose)
            print("fail at " + i);
        try {
            oomAtAllocation(i);
            f();
        } catch (e) {
            // Ignore exceptions.
        }
        more = resetOOMFailure();
        i++;
    } while(more);

    if (verbose)
        print("finished after " + i);
}
oomTest(() => getBacktrace({
    thisprops: true
}));


Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004275cc in JSFunction::nonLazyScript (this=<optimized out>) at js/src/shell/../jsfun.h:422
#0  0x00000000004275cc in JSFunction::nonLazyScript (this=<optimized out>) at js/src/shell/../jsfun.h:422
#1  0x0000000000492208 in nonLazyScript (this=<optimized out>) at js/src/shell/../jsfun.h:422
#2  JSFunction::getOrCreateScript (this=<optimized out>, cx=<optimized out>) at js/src/shell/../jsfun.h:385
#3  0x0000000000707a6a in js::Invoke (cx=cx@entry=0x7ffff6906c00, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:771
#4  0x000000000070868d in js::Invoke (cx=cx@entry=0x7ffff6906c00, thisv=..., fval=..., argc=argc@entry=0, argv=argv@entry=0x0, rval=..., rval@entry=...) at js/src/vm/Interpreter.cpp:823
#5  0x0000000000b49a67 in MaybeCallMethod (cx=cx@entry=0x7ffff6906c00, obj=obj@entry=..., id=..., id@entry=..., vp=vp@entry=...) at js/src/jsobj.cpp:2885
#6  0x0000000000b55e4f in JS::OrdinaryToPrimitive (cx=cx@entry=0x7ffff6906c00, obj=obj@entry=..., hint=hint@entry=JSTYPE_STRING, vp=..., vp@entry=...) at js/src/jsobj.cpp:2931
#7  0x0000000000b561b8 in js::ToPrimitiveSlow (cx=cx@entry=0x7ffff6906c00, preferredType=preferredType@entry=JSTYPE_STRING, vp=..., vp@entry=...) at js/src/jsobj.cpp:3015
#8  0x0000000000c07e7e in ToPrimitive (vp=..., preferredType=JSTYPE_STRING, cx=0x7ffff6906c00) at js/src/jsobj.h:1028
#9  js::ToStringSlow<(js::AllowGC)1> (cx=cx@entry=0x7ffff6906c00, arg=..., arg@entry=...) at js/src/jsstr.cpp:4273
#10 0x0000000000b4c141 in ToString<(js::AllowGC)1> (v=..., cx=0x7ffff6906c00) at js/src/jsstr.h:156
#11 FormatValue (cx=cx@entry=0x7ffff6906c00, vArg=..., bytes=...) at js/src/jsfriendapi.cpp:673
#12 0x0000000000b720e1 in FormatFrame (showThisProps=true, showLocals=false, showArgs=false, num=0, buf=0x7ffff41bd000 "0 anonymous() [\"/home/ubuntu/work/work-2015-10-06-13-56-42/issue7/test/da5bd9a5ff75d298162a61e9d9cbd40473fd9db6.js\":2]\n    this.version = [function]\n    this.options = [function]\n    this.load = [func"..., iter=..., cx=0x7ffff6906c00) at js/src/jsfriendapi.cpp:875
#13 JS::FormatStackDump (cx=cx@entry=0x7ffff6906c00, buf=<optimized out>, buf@entry=0x0, showArgs=false, showLocals=false, showThisProps=true) at js/src/jsfriendapi.cpp:907
#14 0x0000000000604ffe in GetBacktrace (cx=0x7ffff6906c00, argc=<optimized out>, vp=0x7fffffffbc18) at js/src/builtin/TestingFunctions.cpp:2045
#15 0x00007ffff7e5cb48 in ?? ()
#16 0x00007fffffffbc48 in ?? ()
#17 0x00007fffffffbbf0 in ?? ()
#18 0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x0	0
rcx	0x7ffff6ca588d	140737333844109
rdx	0x0	0
rsi	0x7ffff6f7a9d0	140737336814032
rdi	0x7ffff6f791c0	140737336807872
rbp	0x7fffffffae00	140737488334336
rsp	0x7fffffffae00	140737488334336
r8	0x7ffff7fe8780	140737354041216
r9	0x6c6c6568732f6372	7812730952864457586
r10	0x7fffffffabc0	140737488333760
r11	0x7ffff6c27ee0	140737333329632
r12	0x7fffffffafd0	140737488334800
r13	0x0	0
r14	0x1	1
r15	0x7ffff6906c00	140737330048000
rip	0x4275cc <JSFunction::nonLazyScript() const+28>
=> 0x4275cc <JSFunction::nonLazyScript() const+28>:	movl   $0x1a6,0x0
   0x4275d7 <JSFunction::nonLazyScript() const+39>:	callq  0x4983a0 <abort()>

Comment 1

[Lars T Hansen [:lth]]

Does not repro on m-i or on the oom branch at present.

Comment 2

[Lars T Hansen [:lth]]

Probably a bug in GetStackTrace - it does not throw, and it does not clear the exception flag.

Comment 3

[Lars T Hansen [:lth]]

Sorry, GetBackTrace.

Comment 4

[Lars T Hansen [:lth]]

Occasionally triggers this too:
Assertion failure: (*mode & PACKED_TAG_MASK) == 0 && (p.type & ~PACKED_TAG_MASK) == 0, at /Users/lhansen/moz/mozilla-inbound/js/src/jit/Snapshots.cpp:353
Segmentation fault: 11

Comment 5

[Lars T Hansen [:lth]]

Very occasionally GetBackTrace in TestingFunctions.cpp is called with the exception flag already set.  This is probably where the real error is; looking at GetBackTrace, it appears to propagate errors properly.

Comment 6

[Lars T Hansen [:lth]]

Probably the exception flag is set when the arrow function near the end tries to instantiate the literal object that is the argument to the call, and the flag is being lost somehow.

(Changing the arrow function to a regular function does not change this.  And that's good, since the JIT aborts compilation of the arrow function with the error that JSOP_THIS is being used outside a function, this seems suspicious but is not the bug we're looking for.)

Comment 7

[Lars T Hansen [:lth]]

The generated code for the allocation is a NewObject::VMCall.

The other possibility is that the subsequent InitProp has the problem.  This is actually more likely, since if we fail to check the object pointer we should crash in GetBacktrace before getting as far as the stack walk, whereas if we leave off the property the stack walk will go ahead as expected (perhaps with different output).

Comment 8

[Lars T Hansen [:lth]]

Marking s-s for now because it's easy to use this test case to crash the shell.

Comment 9

[Lars T Hansen [:lth]]

Attachment: bug1211913.js

Run like this, for example:

for j in 1 2 3 4 5 6 7 8 ; do ( for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16; do dist/bin/js --fuzzing-safe --thread-count=2 --ion-eager ~/moz/bug1211913.js; done & ) ; done

Output from a run has an assortment of crashes, it's the assert on TestingFunctions.cpp:2034 that worries us:

Assertion failure: [unhandlable oom] Could not allocate ObjectGroup in EnsureTrackPropertyTypes, at /Users/lhansen/moz/mozilla-oom/js/src/jscntxt.cpp:1220
Hit MOZ_CRASH() at /Users/lhansen/moz/mozilla-oom/js/src/jscntxt.cpp:1221
-bash: line 414: 48719 Segmentation fault: 11  dist/bin/js --fuzzing-safe --thread-count=2 --ion-eager ~/moz/bug1211913.js
Assertion failure: [unhandlable oom] Could not allocate ObjectGroup in EnsureTrackPropertyTypes, at /Users/lhansen/moz/mozilla-oom/js/src/jscntxt.cpp:1220
Hit MOZ_CRASH() at /Users/lhansen/moz/mozilla-oom/js/src/jscntxt.cpp:1221
-bash: line 414: 48751 Segmentation fault: 11  dist/bin/js --fuzzing-safe --thread-count=2 --ion-eager ~/moz/bug1211913.js
Assertion failure: !cx->isExceptionPending(), at /Users/lhansen/moz/mozilla-oom/js/src/builtin/TestingFunctions.cpp:2034
Assertion failure: !cx->isExceptionPending(), at /Users/lhansen/moz/mozilla-oom/js/src/builtin/TestingFunctions.cpp:2034
-bash: line 414: 48777 Segmentation fault: 11  dist/bin/js --fuzzing-safe --thread-count=2 --ion-eager ~/moz/bug1211913.js
-bash: line 414: 48779 Segmentation fault: 11  dist/bin/js --fuzzing-safe --thread-count=2 --ion-eager ~/moz/bug1211913.js

Note this is with some extra asserts in the code, I'll attach a patch.

Comment 10

[Lars T Hansen [:lth]]

Attachment: asserts.patch

Comment 11

[Lars T Hansen [:lth]]

I have not been able to make this crash with --no-ion or --no-threads or without --ion-eager.  All of this is on the oom branch though I may not have the latest code.  Failures are basically the same on m-i.

Comment 12

[Lars T Hansen [:lth]]

The above crashes are from a release build, but it does crash with the interesting assertion in debug builds, and sometimes in the debugger.

Comment 13

[Lars T Hansen [:lth]]

Note to self: The trick to figuring this out is probably to backtrace the location of js::ReportOutOfMemory every time it is hit and to look at the last such record when the assertion is hit.  May require gdb on Unix; lldb is pretty buggy and it takes a lot of runs to trigger the assertion.

Comment 14

[Daniel Veditz [:dveditz]]

(In reply to Lars T Hansen [:lth] from comment #8)
> Marking s-s for now because it's easy to use this test case to crash the
> shell.

Is it just the shell? We don't care about crashing the shell if it's shell-only--we could unhide it in that case.

Comment 15

[Lars T Hansen [:lth]]

Well, the crash is shell-only so far but if there's an underlying OOM bug it is probably possible (with very low probability) to crash the browser too.

The problem is that some code - probably not in the shell - leaves the exception flag set without throwing an error.  This probably leaves the VM in a slightly unstable state, though it may not be a big deal, it's hard to say.  We crash in a shell-only testing function, but that's only because that's where we discover the error.  The error is elsewhere.  I found one yesterday (bug 1133630) that is similar.

Comment 16

[Lars T Hansen [:lth]]

No longer reproduces on Linux or Mac OS X (several hundred runs each).  Unassigning from self; probably fixed by other recent OOM work.

Comment 17

[Christian Holler (:decoder)]

Stopped reproducing around October 7, so yes, it likely has been fixed by other OOM work. Marking fixed based on that.