Closed
Bug 1102542
Opened 10 years ago
Closed 10 years ago
CompactingGC: Crash [@ allocated]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla36
People
(Reporter: decoder, Assigned: jonco)
References
Details
(Keywords: crash, testcase, Whiteboard: [jsbugmon:ignore])
Crash Data
Attachments
(1 file)
3.18 KB,
patch
|
terrence
:
review+
|
Details | Diff | Splinter Review |
The following testcase crashes on mozilla-central revision aa72ddfe9f93 (build with --enable-gccompacting --enable-debug --enable-optimize --enable-posix-nspr-emulation --enable-valgrind, run with --fuzzing-safe --thread-count=2): try { gczeal(14); if ((Number.POSITIVE_INFINITY) !== true) { $ERROR('#2: (-1 == new Number(-1)) === true'); } } catch(exc0) {} var a1=Array(0xFFFFFFFF); a1.sort(); Backtrace: Program terminated with signal SIGSEGV, Segmentation fault. #0 allocated (this=0x7fd752556000) at js/src/gc/Heap.h:570 570 MOZ_ASSERT(allocKind <= size_t(FINALIZE_LIMIT)); #0 allocated (this=0x7fd752556000) at js/src/gc/Heap.h:570 #1 js::gc::GCRuntime::decommitAllWithoutUnlocking (this=this@entry=0x298e2c8, lock=...) at js/src/jsgc.cpp:3412 #2 0x00000000008b0291 in onOutOfMallocMemory (lock=..., this=0x298e2c8) at js/src/jsgc.cpp:6455 #3 js::gc::GCRuntime::onOutOfMallocMemory (this=0x298e2c8) at js/src/jsgc.cpp:6443 #4 0x0000000000a3b9ec in JSRuntime::onOutOfMemory (this=<optimized out>, p=p@entry=0x0, nbytes=nbytes@entry=68719476736, cx=0x29ab600) at js/src/vm/Runtime.cpp:763 #5 0x0000000000847f8e in onOutOfMemory (nbytes=68719476736, p=0x0, this=<optimized out>) at js/src/jscntxt.h:269 #6 js::TempAllocPolicy::onOutOfMemory (this=this@entry=0x7fff3e028928, p=p@entry=0x0, nbytes=nbytes@entry=68719476736) at js/src/jsalloc.cpp:16 #7 0x00000000004bfc17 in pod_malloc<JS::Value> (numElems=8589934592, this=0x7fff3e028928) at js/src/jsalloc.h:64 #8 convertToHeapStorage (aNewCap=8589934592, this=0x7fff3e028928) at ../../dist/include/mozilla/Vector.h:706 #9 mozilla::VectorBase<JS::Value, 8ul, js::TempAllocPolicy, js::Vector<JS::Value, 8ul, js::TempAllocPolicy> >::growStorageBy (this=this@entry=0x7fff3e028928, aIncr=aIncr@entry=8589934590) at ../../dist/include/mozilla/Vector.h:797 #10 0x00000000004ab6eb in reserve (aRequest=8589934590, this=0x7fff3e028928) at ../../dist/include/mozilla/Vector.h:830 #11 reserve (newLength=8589934590, this=0x7fff3e028910) at js/src/jsapi.h:176 #12 js::array_sort (cx=0x29ab600, argc=<optimized out>, vp=0x7fff3e0290f8) at js/src/jsarray.cpp:1981 #13 0x0000000000a0af52 in js::CallJSNative (cx=0x29ab600, native=0x4ab2f0 <js::array_sort(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:231 #14 0x00000000009ee117 in js::Invoke (cx=cx@entry=0x29ab600, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:482 #15 0x00000000009f16ab in js::Invoke (cx=cx@entry=0x29ab600, thisv=..., fval=..., argc=argc@entry=0, argv=argv@entry=0x7fff3e0294f8, rval=...) at js/src/vm/Interpreter.cpp:538 #16 0x0000000000681b8f in js::jit::DoCallFallback (cx=0x29ab600, frame=0x7fff3e029570, stub_=<optimized out>, argc=0, vp=0x7fff3e0294e8, res=...) at js/src/jit/BaselineIC.cpp:8986 rax 0x1 1 rbx 0x52556000 140562776023040 rcx 0x56 86 rdx 0x5527eac0 140562823375552 rsi 0x3e028670 140734233740912 rdi 0x298e2c8 43573960 rbp 0x3e028660 140734233740896 rsp 0x3e028620 140734233740832 r8 0x2995540 43603264 r9 0x21000 135168 r10 0x22 34 r11 0x201 513 r12 0x52500008 140562775670792 r13 0x400000 4194304 r14 0x52500000 140562775670784 r15 0x1 1 rip 0x8ad9fb <js::gc::GCRuntime::decommitAllWithoutUnlocking(js::AutoLockGC const&)+91> => 0x8ad9fb <js::gc::GCRuntime::decommitAllWithoutUnlocking(js::AutoLockGC const&)+91>: cmpb $0x17,0x14(%rbx) 0x8ad9ff <js::gc::GCRuntime::decommitAllWithoutUnlocking(js::AutoLockGC const&)+95>: ja 0x8ada5f <js::gc::GCRuntime::decommitAllWithoutUnlocking(js::AutoLockGC const&)+191> Not s-s because compacting GC is not enabled yet in any builds.
Assignee | ||
Comment 1•10 years ago
|
||
This is happening because in debug builds we unmap relocated arenas and keep them around to the next GC to catch any memory accesses to them. This is confusing decommitAllWithoutUnlocking() which tries to access the protected memory. The fix is to release those arenas first if necessary. One thing I'm not clear on however is why we necessarily need to do this without releasing the GC lock. Anyway, I made release that happens from here also do the same, but it does mean we can't call expireChunksAndArenas() as that releases the lock.
Assignee: nobody → jcoppeard
Attachment #8526708 -
Flags: review?(terrence)
Comment 2•10 years ago
|
||
Comment on attachment 8526708 [details] [diff] [review] bug1102542-release-relocated-arenas Review of attachment 8526708 [details] [diff] [review]: ----------------------------------------------------------------- I like this approach -- I think it makes more sense to make our OOM code aware of compaction than it does to be overly general here. Previously we were re-using decommitArenas and since that unlocks, the background parsing thread could grab more memory before we return to the original failed malloc -- not ideal.
Attachment #8526708 -
Flags: review?(terrence) → review+
Assignee | ||
Comment 3•10 years ago
|
||
Ah cheers, I didn't think of the background parsing thread. https://hg.mozilla.org/integration/mozilla-inbound/rev/69d3b8413102
https://hg.mozilla.org/mozilla-central/rev/69d3b8413102
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in
before you can comment on or make changes to this bug.
Description
•