Closed
Bug 1329665
Opened 8 years ago
Closed 8 years ago
Assertion failure: fallibleScope_ ([OOM] Cannot allocate a new chunk in an infallible scope.), at js/src/ds/LifoAlloc.cpp:105
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla53
Tracking | Status | |
---|---|---|
firefox51 | --- | unaffected |
firefox52 | --- | disabled |
firefox53 | --- | fixed |
People
(Reporter: decoder, Assigned: nbp)
References
Details
(4 keywords, Whiteboard: [fuzzblocker] [jsbugmon:bisect])
Attachments
(2 files)
9.79 KB,
text/plain
|
Details | |
1003 bytes,
patch
|
h4writer
:
review+
|
Details | Diff | Splinter Review |
The following testcase crashes on mozilla-central revision 701868bfddcb (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug --enable-optimize, run with --fuzzing-safe --ion-aa=flow-sensitive --ion-eager): See attachment. Backtrace: received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff48fb700 (LWP 18113)] js::LifoAlloc::getOrCreateChunk (this=this@entry=0x7ffff0338440, n=n@entry=56) at js/src/ds/LifoAlloc.cpp:105 #0 js::LifoAlloc::getOrCreateChunk (this=this@entry=0x7ffff0338440, n=n@entry=56) at js/src/ds/LifoAlloc.cpp:105 #1 0x00000000005f6d03 in js::LifoAlloc::allocImpl (n=56, this=0x7ffff0338440) at js/src/ds/LifoAlloc.h:225 #2 js::LifoAlloc::allocInfallible (this=0x7ffff0338440, n=56) at js/src/ds/LifoAlloc.h:291 #3 0x000000000064102c in js::jit::TempAllocator::allocateInfallible (bytes=56, this=<optimized out>) at js/src/jit/JitAllocPolicy.h:44 #4 js::jit::TempObject::operator new (alloc=..., nbytes=56) at js/src/jit/JitAllocPolicy.h:162 #5 js::jit::FlowAliasAnalysis::saveStoreDependency (this=this@entry=0x7ffff48faa70, ins=ins@entry=0x7ffff0577450, prevStores=...) at js/src/jit/FlowAliasAnalysis.cpp:818 #6 0x000000000065747f in js::jit::FlowAliasAnalysis::processStore (this=this@entry=0x7ffff48faa70, blockInfo=..., store=store@entry=0x7ffff0577450) at js/src/jit/FlowAliasAnalysis.cpp:518 #7 0x000000000065963f in js::jit::FlowAliasAnalysis::analyze (this=<optimized out>) at js/src/jit/FlowAliasAnalysis.cpp:487 #8 0x000000000065a745 in js::jit::OptimizeMIR (mir=mir@entry=0x7ffff05021c8) at js/src/jit/Ion.cpp:1698 #9 0x000000000065b9d6 in js::jit::CompileBackEnd (mir=mir@entry=0x7ffff05021c8) at js/src/jit/Ion.cpp:2067 #10 0x0000000000b0ebbe in js::HelperThread::handleIonWorkload (this=this@entry=0x7ffff6948460, locked=...) at js/src/vm/HelperThreads.cpp:1511 #11 0x0000000000b0f835 in js::HelperThread::threadLoop (this=this@entry=0x7ffff6948460) at js/src/vm/HelperThreads.cpp:1874 #12 0x0000000000b0fb75 in js::HelperThread::ThreadMain (arg=0x7ffff6948460) at js/src/vm/HelperThreads.cpp:1407 #13 0x0000000000b1a462 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul> (this=0x7ffff69200a0) at js/src/threading/Thread.h:234 #14 js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start (aPack=0x7ffff69200a0) at js/src/threading/Thread.h:227 #15 0x00007ffff7bc16fa in start_thread (arg=0x7ffff48fb700) at pthread_create.c:333 #16 0x00007ffff6c38b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 rax 0x204e520 33875232 rbx 0x1217988 18971016 rcx 0x7ffff6c28a2d 140737333332525 rdx 0x0 0 rsi 0x7ffff6ef7770 140737336276848 rdi 0x7ffff6ef6540 140737336272192 rbp 0x7ffff48fa6f0 140737296443120 rsp 0x7ffff48fa630 140737296442928 r8 0x7ffff6ef7770 140737336276848 r9 0x7ffff48fb700 140737296447232 r10 0x58 88 r11 0x7ffff6b9f750 140737332770640 r12 0x7ffff0580ff0 140737225691120 r13 0x7ffff0338440 140737223296064 r14 0x38 56 r15 0x0 0 rip 0x825030 <js::LifoAlloc::getOrCreateChunk(unsigned long)+944> => 0x825030 <js::LifoAlloc::getOrCreateChunk(unsigned long)+944>: movl $0x0,0x0 0x82503b <js::LifoAlloc::getOrCreateChunk(unsigned long)+955>: ud2 This one looks significantly different to bug 1329651 that I just filed.
Reporter | ||
Comment 1•8 years ago
|
||
Updated•8 years ago
|
Version: Trunk → 53 Branch
Updated•8 years ago
|
Component: JavaScript Engine → Extension Compatibility
Product: Core → Firefox
Comment 2•8 years ago
|
||
Sorry I have too many bugs open at once. this was an accident
Component: Extension Compatibility → JavaScript Engine
Product: Firefox → Core
Reporter | ||
Comment 3•8 years ago
|
||
This bug is now triggering very often, marking as fuzzblocker.
Flags: needinfo?(nicolas.b.pierron)
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update,bisect][fuzzblocker]
Assignee | ||
Comment 4•8 years ago
|
||
I honestly did not beleived this line was the faulty one, but it was. The reason I did not beleive it is that we are using vectors in which we append data into. When we append into a vector, we run ensureBallast right after the allocation. The reason is that the StoreDependency's vector has a reserve space of 1, which means that the first append could be an infallible append and the init function could be infallible. Then later, other vectors might not be resized because we already have large allocations. So, this new allocation can be the only looping allocation, thus making it fallible solves the issue. Thanks to this assertion, even if the code was written as being checked against allocation failures, already, the allocator being used was the infallible one.
Attachment #8828751 -
Flags: review?(hv1989)
Comment 5•8 years ago
|
||
Comment on attachment 8828751 [details] [diff] [review] Use fallible allocator in FlowAliasAnalysis::saveStoreDependency. Review of attachment 8828751 [details] [diff] [review]: ----------------------------------------------------------------- Good find!
Attachment #8828751 -
Flags: review?(hv1989) → review+
Pushed by npierron@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/ae8caa5d668a Use fallible allocator in FlowAliasAnalysis::saveStoreDependency. r=h4writer
Updated•8 years ago
|
Whiteboard: [jsbugmon:update,bisect][fuzzblocker] → [fuzzblocker] [jsbugmon:bisect]
Comment 7•8 years ago
|
||
JSBugMon: Cannot process bug: Error: Unsupported branch "53 Branch" required by bug
Comment 8•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/ae8caa5d668a
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Updated•8 years ago
|
Assignee: nobody → nicolas.b.pierron
status-firefox51:
--- → unaffected
status-firefox52:
--- → unaffected
Version: 53 Branch → Trunk
Comment 9•8 years ago
|
||
Actually, looks like 52 might be affected? Please nominate this for Aurora approval if that's indeed the case.
Assignee | ||
Comment 10•8 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #9) > Actually, looks like 52 might be affected? Please nominate this for Aurora > approval if that's indeed the case. This code is currently disabled, and only used by fuzzers with the --ion-aa=flow-sensitive JS Shell flag. I don't think this would be necessary to backport unless fuzzers are also blocked for the same reason on older branches.
Flags: needinfo?(nicolas.b.pierron)
Updated•8 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•