Closed Bug 1102542 Opened 10 years ago Closed 9 years ago

CompactingGC: Crash [@ allocated]

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla36

People

(Reporter: decoder, Assigned: jonco)

References

Details

(Keywords: crash, testcase, Whiteboard: [jsbugmon:ignore])

Crash Data

Attachments

(1 file)

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.
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 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+
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: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.