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)
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)
1.29 KB,
patch
|
terrence
:
review+
|
Details | Diff | Splinter Review |
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 | ||
Comment 1•9 years ago
|
||
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)
Updated•9 years ago
|
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.
Description
•