Closed Bug 1161303 Opened 9 years ago Closed 9 years ago

Assertion failure: maybecx->isThrowingOutOfMemory(), at js/src/jscntxt.cpp:937

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla40
Tracking Status
firefox40 --- fixed

People

(Reporter: decoder, Assigned: jonco)

References

Details

(Keywords: assertion, regression, testcase, Whiteboard: [jsbugmon:update,bisect][fuzzblocker])

Attachments

(1 file)

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

function f(x) {
    for (var i = 0; i < 90; Math-- ) {
        [(x, 2)];
        try { g(); } catch (t) {}     
    }
}
f(2);



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000a575b8 in js::ExclusiveContext::recoverFromOutOfMemory (this=this@entry=0x7ffff691b4e0) at js/src/jscntxt.cpp:937
#0  0x0000000000a575b8 in js::ExclusiveContext::recoverFromOutOfMemory (this=this@entry=0x7ffff691b4e0) at js/src/jscntxt.cpp:937
#1  0x00000000005013d8 in js::NewObjectCache::newObjectFromHit (this=<optimized out>, cx=0x7ffff691b4e0, entryIndex=<optimized out>, heap=<optimized out>) at js/src/vm/Runtime-inl.h:65
#2  0x00000000004f1ce4 in NewArray<268435456u> (cxArg=0x7ffff691b4e0, length=1, protoArg=..., newKind=js::GenericObject) at js/src/jsarray.cpp:3312
#3  0x00000000004f23a1 in NewDenseFullyAllocatedArray (newKind=<optimized out>, proto=..., length=1, cx=0x7ffff691b4e0) at js/src/jsarray.cpp:3389
#4  js::NewDenseArray (cx=0x7ffff691b4e0, length=1, group=..., group@entry=..., allocating=js::NewArray_FullyAllocating, convertDoubleElements=convertDoubleElements@entry=false) at js/src/jsarray.cpp:3423
#5  0x000000000097895f in js::jit::RNewArray::recover (this=0x7fffffff9cb8, cx=<optimized out>, iter=...) at js/src/jit/Recover.cpp:1221
#6  0x000000000092a883 in js::jit::SnapshotIterator::computeInstructionResults (this=this@entry=0x7fffffff9fd0, cx=cx@entry=0x7ffff691b4e0, results=results@entry=0x7fffffffbcf8) at js/src/jit/JitFrames.cpp:2223
#7  0x000000000092aab6 in js::jit::SnapshotIterator::initInstructionResults (this=this@entry=0x7fffffffa730, fallback=...) at js/src/jit/JitFrames.cpp:2177
#8  0x0000000000862e87 in init (cx=0x7ffff691b4e0, this=0x7fffffffa730) at js/src/jit/BaselineBailouts.cpp:435
#9  js::jit::BailoutIonToBaseline (cx=cx@entry=0x7ffff691b4e0, activation=0x7fffffffbc30, iter=..., invalidate=invalidate@entry=true, bailoutInfo=bailoutInfo@entry=0x7fffffffaab0, excInfo=excInfo@entry=0x7fffffffafc0) at js/src/jit/BaselineBailouts.cpp:1463
#10 0x0000000000866d6e in js::jit::ExceptionHandlerBailout (cx=cx@entry=0x7ffff691b4e0, frame=..., rfe=rfe@entry=0x7fffffffb9b8, excInfo=..., overrecursed=overrecursed@entry=0x7fffffffae80) at js/src/jit/Bailouts.cpp:210
#11 0x000000000090f85b in HandleExceptionIon (overrecursed=0x7fffffffae80, rfe=0x7fffffffb9b8, frame=..., cx=0x7ffff691b4e0) at js/src/jit/JitFrames.cpp:486
#12 js::jit::HandleException (rfe=0x7fffffffb9b8) at js/src/jit/JitFrames.cpp:822
#13 0x00007ffff7fe8608 in ?? ()
#14 0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x0	0
rcx	0x7ffff6ca53cd	140737333842893
rdx	0x0	0
rsi	0x7ffff6f7a9d0	140737336814032
rdi	0x7ffff6f791c0	140737336807872
rbp	0x7fffffff9980	140737488329088
rsp	0x7fffffff9980	140737488329088
r8	0x7ffff7fe0780	140737354008448
r9	0x6372732f736a2f6c	7165916604736876396
r10	0x7fffffff9740	140737488328512
r11	0x7ffff6c27960	140737333328224
r12	0x7ffff69469d0	140737330309584
r13	0x7ffff69469e8	140737330309608
r14	0x7ffff691b4e0	140737330132192
r15	0x0	0
rip	0xa575b8 <js::ExclusiveContext::recoverFromOutOfMemory()+120>
=> 0xa575b8 <js::ExclusiveContext::recoverFromOutOfMemory()+120>:	movl   $0x3a9,0x0
   0xa575c3 <js::ExclusiveContext::recoverFromOutOfMemory()+131>:	callq  0x48eb50 <abort()>


Marking as fuzzblocker because this occurs quite frequently.
Assignee: nobody → jcoppeard
Blocks: 1155618
Introduced by my previous patch because I changed NewObjectCache::newObjectFromHit() to check for null and recover from the reported OOM before I fixed Allocate<T, NoGC>() to not report OOM on failure.
Attachment #8602047 - Flags: review?(terrence)
Attachment #8602047 - Flags: review?(terrence) → review+
https://hg.mozilla.org/mozilla-central/rev/ff666faf8a5d
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
You need to log in before you can comment on or make changes to this bug.