The following testcase crashes on mozilla-central built with --enable-exact-rooting --enable-gcgenerational, revision cf485c48b52f (run with --fuzzing-safe): gczeal(9, 1) var { ArrayType, StructType, uint32 } = TypedObject; var L = 1024; var Matrix = uint32.array(L, 2); var matrix = new Matrix(); assertParallelExecSucceeds( function(points) { for (var i = 0; i < L; i++) assertEq(matrix[i][0], i); } ); function assertParallelExecSucceeds(opFunction) { while (true) { try { var result = opFunction({mode:"par"}); } catch (e) {} } }

Crash trace: Program received signal SIGSEGV, Segmentation fault. getFixedSlot (slot=3, this=0x7ffff545f160) at js/src/vm/ObjectImpl.h:762 762 MOZ_ASSERT(slot < numFixedSlots()); (gdb) bt 16 #0 getFixedSlot (slot=3, this=0x7ffff545f160) at js/src/vm/ObjectImpl.h:762 #1 nextView (this=(const js::ArrayBufferViewObject * const) 0x7ffff545f160 Cannot access memory at address 0xdadadadadadadada) at js/src/vm/ArrayBufferObject.h:248 #2 obj_trace (obj=(JSObject *) 0x7ffff545d6c0 [object ArrayBuffer], trc=0x182c2e8) at js/src/vm/ArrayBufferObject.cpp:770 #3 js::ArrayBufferObject::obj_trace (trc=0x182c2e8, obj=(JSObject *) 0x7ffff545d6c0 [object ArrayBuffer]) at js/src/vm/ArrayBufferObject.cpp:746 #4 0x000000000054ac11 in js::GCMarker::processMarkStackTop (this=0x182c2e8, budget=...) at js/src/gc/Marking.cpp:1527 #5 0x00000000005113bd in js::GCMarker::drainMarkStack (this=0x182c2e8, budget=...) at js/src/gc/Marking.cpp:1580 #6 0x00000000008528f2 in DrainMarkStack (phase=js::gcstats::PHASE_MARK, sliceBudget=..., rt=0x182be90) at js/src/jsgc.cpp:4134 #7 IncrementalCollectSlice (rt=0x182be90, budget=<optimized out>, reason=JS::gcreason::DEBUG_GC, gckind=js::GC_NORMAL) at js/src/jsgc.cpp:4694 #8 0x000000000085505e in GCCycle (rt=0x182be90, incremental=true, budget=-2, gckind=js::GC_NORMAL, reason=JS::gcreason::DEBUG_GC) at js/src/jsgc.cpp:4858 #9 0x000000000085571b in Collect (reason=JS::gcreason::DEBUG_GC, gckind=js::GC_NORMAL, budget=-2, incremental=true, rt=0x182be90) at js/src/jsgc.cpp:4996 #10 Collect (rt=0x182be90, incremental=true, budget=-2, gckind=js::GC_NORMAL, reason=JS::gcreason::DEBUG_GC) at js/src/jsgc.cpp:4918 #11 0x00000000008561c8 in js::gc::CheckAllocatorState<(js::AllowGC)1> (cx=<optimized out>, kind=js::gc::FINALIZE_SHAPE) at js/src/jsgcinlines.h:432 #12 0x00000000008d3345 in js::gc::AllocateNonObject<js::Shape, (js::AllowGC)1> (cx=0x1840c60) at js/src/jsgcinlines.h:515 #13 0x000000000087d134 in js_NewGCShape (cx=0x1840c60) at js/src/jsgcinlines.h:624 #14 js::PropertyTree::newShape (this=<optimized out>, cx=<optimized out>) at js/src/jspropertytree.cpp:36 #15 0x00000000009605b9 in js::EmptyShape::getInitialShape (cx=0x1840c60, clasp=0x17b9680, proto=..., parent=<optimized out>, metadata=0x0, nfixed=7, objectFlags=0) at js/src/vm/Shape.cpp:1723 (More stack frames follow...) (gdb) x /i $pc => 0x8f6221 <js::ArrayBufferObject::obj_trace(JSTracer*, JSObject*)+321>: cmpl $0x1fffffff,0x10(%rax) (gdb) info reg rax rax 0xdadadadadadadada -2676586395008836902

I'm seeing more crashes that involve ArrayBufferObject in traces and TypedObject in the test. These might all be dups, so marking this one as a fuzzblocker.

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 83332ca5291a).

Seems to be gone already, but making a bisection to be sure.

I think this is the same issues as bug 981462.

JSBugMon: Fix Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first good revision is: changeset: http://hg.mozilla.org/mozilla-central/rev/e360e4742124 parent: 174583:260154a65e57 parent: 174517:cf485c48b52f user: Carsten "Tomcat" Book date: Thu Mar 20 14:18:00 2014 +0100 summary: Merge mozilla-central to mozilla-inbound Not all ancestors of this changeset have been checked. Use bisect --extend to continue the bisection from the common ancestor, 79a62689ba10. This iteration took 144.298 seconds to run. Oops! We didn't test rev 260154a65e57, a parent of the blamed revision! Let's do that now. We did not test rev 260154a65e57 because it is not a descendant of either cf485c48b52f or c69c55582faa. Rev 260154a65e57: Updating... Compiling... Testing... [Uninteresting] It didn't crash. (10.017 seconds) good (not interesting) As expected, the parent's label is the opposite of the blamed rev's label. Bisect lied to us! Parent rev 260154a65e57 was also good! Bisect blamed the merge because our initial range did not include one of the parents. The common ancestor of 260154a65e57 and cf485c48b52f is 79a62689ba10. Rev 79a62689ba10: Updating... Compiling... Testing... Exit status: CRASHED signal 11 (SIGSEGV) (1.222 seconds) bad (interesting) Consider re-running autoBisect with -s 79a62689ba10 -e e360e4742124 in a configuration where earliestWorking is before the common ancestor.

Comment 7 is likely bogus, but anyway we shouldn't worry since it is a dupe of bug 981462 as Jon marked it.