987439 - GenerationalGC: Crash [@ getFixedSlot] or Crash [@ js::ObjectImpl::compartment] with use-after-free

Status: RESOLVED DUPLICATE of bug 981462

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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) {}
  }
}

Comment 1

[Christian Holler (:decoder)]

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

Comment 2

[Christian Holler (:decoder)]

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.

Comment 3

[Christian Holler (:decoder)]

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

Comment 4

[Christian Holler (:decoder)]

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

Comment 5

[Jon Coppeard (:jonco)]

I think this is the same issues as bug 981462.

Comment 7

[Christian Holler (:decoder)]

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 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

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