1252329 - Assertion failure: p, at js/src/vm/ObjectGroup.cpp:1676 with OOM

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 4972f77869de (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --thread-count=2 --ion-eager --ion-extra-checks --ion-offthread-compile=off):

var lfcode = new Array();
lfcode.push("5");
lfcode.push(`
gczeal(8, 2);
try {
    [new String, y]
} catch (e) {}
oomAfterAllocations(50);
try {
    (5).replace(r, () => {});
} catch (x) {}
`);
while (true) {
  var file = lfcode.shift(); if (file == undefined) { break; }
  loadFile(file)
}
function loadFile(lfVarx) {
    if (lfVarx.substr(-3) != ".js" && lfVarx.length != 1) {
        switch (lfRunTypeId) {
            case 5: 
                var lfGlobal = newGlobal();
                for (lfLocal in this) {}
                lfGlobal.offThreadCompileScript(lfVarx);
                lfGlobal.runOffThreadScript();
        }
    } else if (!isNaN(lfVarx)) {
        lfRunTypeId = parseInt(lfVarx);
    }
}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000ad9779 in js::ObjectGroupCompartment::removeDefaultNewGroup (this=this@entry=0x7ffff694bb08, clasp=clasp@entry=0x0, proto=..., associated=<optimized out>) at js/src/vm/ObjectGroup.cpp:1676
#0  0x0000000000ad9779 in js::ObjectGroupCompartment::removeDefaultNewGroup (this=this@entry=0x7ffff694bb08, clasp=clasp@entry=0x0, proto=..., associated=<optimized out>) at js/src/vm/ObjectGroup.cpp:1676
#1  0x0000000000b91efe in js::ObjectGroup::detachNewScript (this=this@entry=0x7ffff7eb3a60, writeBarrier=writeBarrier@entry=false, replacement=replacement@entry=0x0) at js/src/vm/TypeInference.cpp:2917
#2  0x0000000000b9124b in js::ObjectGroup::maybeClearNewScriptOnOOM (this=0x7ffff7eb3a60) at js/src/vm/TypeInference.cpp:2944
#3  0x0000000000b91462 in js::TypeZone::clearAllNewScriptsOnOOM (this=<optimized out>) at js/src/vm/TypeInference.cpp:4433
#4  0x00000000008e00f1 in js::gc::GCRuntime::sweepTypesAfterCompacting (this=this@entry=0x7ffff695d430, zone=zone@entry=0x7ffff698b000) at js/src/jsgc.cpp:2454
#5  0x00000000008e0148 in js::gc::GCRuntime::sweepZoneAfterCompacting (this=0x7ffff695d430, zone=zone@entry=0x7ffff698b000) at js/src/jsgc.cpp:2462
#6  0x00000000008e3f0c in js::gc::GCRuntime::updatePointersToRelocatedCells (this=this@entry=0x7ffff695d430, zone=zone@entry=0x7ffff698b000) at js/src/jsgc.cpp:2815
#7  0x0000000000907d55 in js::gc::GCRuntime::compactPhase (this=this@entry=0x7ffff695d430, reason=reason@entry=JS::gcreason::DEBUG_GC, sliceBudget=...) at js/src/jsgc.cpp:5739
#8  0x00000000009082a7 in js::gc::GCRuntime::incrementalCollectSlice (this=this@entry=0x7ffff695d430, budget=..., reason=reason@entry=JS::gcreason::DEBUG_GC) at js/src/jsgc.cpp:6240
#9  0x0000000000909200 in js::gc::GCRuntime::gcCycle (this=this@entry=0x7ffff695d430, nonincrementalByAPI=nonincrementalByAPI@entry=false, budget=..., reason=reason@entry=JS::gcreason::DEBUG_GC) at js/src/jsgc.cpp:6415
#10 0x0000000000909741 in js::gc::GCRuntime::collect (this=this@entry=0x7ffff695d430, nonincrementalByAPI=nonincrementalByAPI@entry=false, budget=..., reason=reason@entry=JS::gcreason::DEBUG_GC) at js/src/jsgc.cpp:6521
#11 0x000000000090b0ac in js::gc::GCRuntime::runDebugGC (this=this@entry=0x7ffff695d430) at js/src/jsgc.cpp:7050
#12 0x0000000000c0a1ba in js::gc::GCRuntime::gcIfNeededPerAllocation (this=this@entry=0x7ffff695d430, cx=cx@entry=0x7ffff6907800) at js/src/gc/Allocator.cpp:28
#13 0x0000000000c1765f in js::gc::GCRuntime::checkAllocatorState<(js::AllowGC)1> (this=0x7ffff695d430, cx=0x7ffff6907800, kind=js::gc::BASE_SHAPE) at js/src/gc/Allocator.cpp:55
#14 0x0000000000c19574 in js::Allocate<js::BaseShape, (js::AllowGC)1> (cx=cx@entry=0x7ffff6907800) at js/src/gc/Allocator.cpp:213
#15 0x0000000000b28aa8 in js::BaseShape::getUnowned (cx=cx@entry=0x7ffff6907800, base=...) at js/src/vm/Shape.cpp:1276
#16 0x0000000000b2bf0d in js::EmptyShape::getInitialShape (cx=cx@entry=0x7ffff6907800, clasp=clasp@entry=0x1c28c00 <js::NumberObject::class_>, proto=..., nfixed=<optimized out>, objectFlags=<optimized out>) at js/src/vm/Shape.cpp:1505
#17 0x0000000000946cf4 in NewObject (cx=0x7ffff6907800, group=..., kind=js::gc::OBJECT2_BACKGROUND, newKind=js::SingletonObject, initialShapeFlags=<optimized out>) at js/src/jsobj.cpp:663
#18 0x000000000094710a in js::NewObjectWithGivenTaggedProto (cxArg=cxArg@entry=0x7ffff6907800, clasp=0x1c28c00 <js::NumberObject::class_>, proto=..., allocKind=js::gc::OBJECT2_BACKGROUND, newKind=newKind@entry=js::SingletonObject, initialShapeFlags=initialShapeFlags@entry=0) at js/src/jsobj.cpp:729
#19 0x0000000000a0e28f in NewObjectWithGivenTaggedProto (initialShapeFlags=0, newKind=js::SingletonObject, proto=..., clasp=0x1c28c00 <js::NumberObject::class_>, cx=0x7ffff6907800) at js/src/jsobjinlines.h:628
#20 NewObjectWithGivenProto (newKind=js::SingletonObject, proto=..., clasp=0x1c28c00 <js::NumberObject::class_>, cx=0x7ffff6907800) at js/src/jsobjinlines.h:663
#21 NewNativeObjectWithGivenProto (newKind=js::SingletonObject, proto=..., clasp=0x1c28c00 <js::NumberObject::class_>, cx=0x7ffff6907800) at js/src/vm/NativeObject-inl.h:338
#22 CreateBlankProto (cx=cx@entry=0x7ffff6907800, clasp=clasp@entry=0x1c28c00 <js::NumberObject::class_>, proto=..., proto@entry=..., global=...) at js/src/vm/GlobalObject.cpp:522
#23 0x0000000000a1de15 in js::GlobalObject::createBlankPrototype (this=<optimized out>, cx=cx@entry=0x7ffff6907800, clasp=clasp@entry=0x1c28c00 <js::NumberObject::class_>) at js/src/vm/GlobalObject.cpp:537
#24 0x000000000094cc17 in js::InitNumberClass (cx=cx@entry=0x7ffff6907800, obj=..., obj@entry=...) at js/src/jsnum.cpp:1138
#25 0x0000000000a1d9b1 in js::GlobalObject::resolveConstructor (cx=cx@entry=0x7ffff6907800, global=..., key=key@entry=JSProto_Number) at js/src/vm/GlobalObject.cpp:163
#26 0x0000000000a1dadc in js::GlobalObject::ensureConstructor (cx=cx@entry=0x7ffff6907800, global=..., global@entry=..., key=key@entry=JSProto_Number) at js/src/vm/GlobalObject.cpp:116
#27 0x0000000000abc528 in getOrCreateNumberPrototype (global=..., cx=0x7ffff6907800) at js/src/vm/GlobalObject.h:378
#28 js::GetProperty (cx=cx@entry=0x7ffff6907800, v=..., name=..., name@entry=..., vp=vp@entry=...) at js/src/vm/Interpreter.cpp:4050
#29 0x00000000007d9587 in js::jit::ComputeGetPropResult (cx=cx@entry=0x7ffff6907800, frame=<optimized out>, op=op@entry=JSOP_CALLPROP, name=name@entry=..., val=..., val@entry=..., res=res@entry=...) at js/src/jit/SharedIC.cpp:3017
#30 0x00000000007e286e in js::jit::DoGetPropFallback (cx=0x7ffff6907800, payload=<optimized out>, stub_=<optimized out>, val=..., res=...) at js/src/jit/SharedIC.cpp:3079
#31 0x00007ffff7fec06b in ?? ()
[...]
#45 0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x7ffff694bb08	140737330330376
rcx	0x7ffff6ca588d	140737333844109
rdx	0x0	0
rsi	0x7ffff6f7a9d0	140737336814032
rdi	0x7ffff6f791c0	140737336807872
rbp	0x7fffffff96c0	140737488328384
rsp	0x7fffffff9650	140737488328272
r8	0x7ffff7fdf7c0	140737354004416
r9	0x6372732f736a2f6c	7165916604736876396
r10	0x7fffffff9410	140737488327696
r11	0x7ffff6c27ee0	140737333329632
r12	0x0	0
r13	0x0	0
r14	0x7ffff694bb08	140737330330376
r15	0x7ffff695d430	140737330402352
rip	0xad9779 <js::ObjectGroupCompartment::removeDefaultNewGroup(js::Class const*, js::TaggedProto, JSObject*)+153>
=> 0xad9779 <js::ObjectGroupCompartment::removeDefaultNewGroup(js::Class const*, js::TaggedProto, JSObject*)+153>:	movl   $0x68c,0x0
   0xad9784 <js::ObjectGroupCompartment::removeDefaultNewGroup(js::Class const*, js::TaggedProto, JSObject*)+164>:	callq  0x4a6780 <abort()>


I've been hitting this bug for a long time without a reliable test. If you can fix this while it still reproduces, that'd be awesome!

Comment 1

[Fuzzing Team]

JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20151122071711" and the hash "26bf115402e27a4f24de8a040f8b36ac8e7d8ce4".
The "bad" changeset has the timestamp "20151122113013" and the hash "94da01072e14304a014958b7c0f8dff1abf477df".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=26bf115402e27a4f24de8a040f8b36ac8e7d8ce4&tochange=94da01072e14304a014958b7c0f8dff1abf477df

Comment 2

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

Not sure if the regression window is accurate for this OOM bug.

Terrence/Jon, are you likely to be able to know what is going on here? (GC is on the stack)

Comment 3

[Fuzzing Team]

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

Comment 4

[Jon Coppeard (:jonco)]

We're hitting OOM during compacting and AutoClearTypeInferenceStateOnOOM is trying to clear new scripts.  Unfortunately that involves looking up entries in ObjectGroupCompartment's defaultNewTable and the ObjectGroups' prototypes haven't been updated yet.  We fail to match the table entries, triggering the assertion.

Comment 5

[Jon Coppeard (:jonco)]

Attachment: bug1252329-compacting-oom

The fix is twofold: firstly, in ObjectGroupCompartment::fixupNewTableAfterMovingGC we update the prototype for any object group referred to by a table entry.  This means we can successfully lookup table entries straight away (ObjectGroups have their pointers updated later and possibly on a background thread).  Then we just need to forward the pointers in ObjectGroup::detachNewScript.

Comment 6

[Terrence Cole [:terrence]]

Comment on attachment 8727419 [details] [diff] [review]
bug1252329-compacting-oom

Review of attachment 8727419 [details] [diff] [review]:
-----------------------------------------------------------------

This is pretty ugly, but I don't have a better solution.

Comment 7

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6d88a7fdf970

Comment 8

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/eee943e51af2

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/6d88a7fdf970
https://hg.mozilla.org/mozilla-central/rev/eee943e51af2

Comment 10

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

Are we able to backport this at least to mozilla-aurora?

Comment 11

[Jon Coppeard (:jonco)]

Attachment: bug1252329-compacting-oom-aurora

Approval Request Comment
[Feature/regressing bug #]: Bug 650161.
[User impact if declined]: Possible crash on OOM.
[Describe test coverage new/current, TreeHerder]: On m-c for over a month.
[Risks and why]: Low.
[String/UUID change made/needed]: None.

Comment 12

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8742379 [details] [diff] [review]
bug1252329-compacting-oom-aurora

Possible OOM crash fix, baked in Nightly for almost a month, Aurora47+

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/834fed3f42db