1021089 - Assertion failure: shape_, at vm/ObjectImpl.h:546 or Crash [@ getClass]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision 51b428be6213 (run with --fuzzing-safe --ion-eager):


gczeal(2,4);
testcase();
function testcase() {
    var o = {};
    Object.defineProperty(o, "foo", { "\ucaeb" : "hello", configurable: true});
    Object.preventExtensions(o);
    Object.defineProperty(o, "foo", { get: function() { return 5;} });
    var fooDescrip = Object.getOwnPropertyDescriptor(o, "foo");
}

Comment 1

[Christian Holler (:decoder)]

Attachment: [crash-signature] Machine-readable crash signature

Comment 2

[Christian Holler (:decoder)]

Opt-crash:


Program received signal SIGSEGV, Segmentation fault.
0x0810ac05 in getClass (this=0xf6900020) at js/src/irregexp/RegExpEngine.cpp:4766
4766    }
#0  0x0810ac05 in getClass (this=0xf6900020) at js/src/irregexp/RegExpEngine.cpp:4766
#1  is<js::ArrayObject> (this=0xf6900020) at js/src/jsobj.h:1126
#2  GetObjectAllocKindForCopy (obj=0xf6900020, rt=0x91fa7e8) at js/src/gc/Nursery.cpp:373
#3  js::Nursery::moveToTenured (this=0x91fb2f0, trc=0xffffb390, src=0xf6900020) at js/src/gc/Nursery.cpp:560
#4  0x08116329 in markSlot (slotp=0x923b150, trc=0xffffb390, this=<optimized out>) at js/src/gc/Nursery.cpp:552
#5  markSlots (vp=<optimized out>, end=<optimized out>, trc=<optimized out>, this=<optimized out>) at js/src/gc/Nursery.cpp:534
#6  traceObject (obj=<optimized out>, trc=0xffffb390, this=0x91fb2f0) at js/src/gc/Nursery.cpp:521
#7  collectToFixedPoint (tenureCounts=..., trc=0xffffb390, this=0x91fb2f0) at js/src/gc/Nursery.cpp:493
eax     0xffffff87      -121
=> 0x810ac05 <js::Nursery::moveToTenured(js::gc::MinorCollectionTracer*, JSObject*)+53>:        mov    (%eax),%eax


Marking s-s until investigated.

Comment 3

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 5e8e9d864a4d).
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/e4279ded250d
user:        Eric Faust
date:        Tue Jun 03 12:05:48 2014 -0700
summary:     Bug 997894 - Part 2: Replace existing externally rooted PropDesc sites with Rooted<PropDesc>. (r=terrence)

This iteration took 0.834 seconds to run.

Comment 4

[Christian Holler (:decoder)]

JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/a1199e0dd68b
parent:      186746:fe14647a422d
parent:      186589:51b428be6213
user:        Carsten "Tomcat" Book
date:        Thu Jun 05 09:03:12 2014 +0200
summary:     Merge mozilla-central to mozilla-inbound on a CLOSED TREE

Not all ancestors of this changeset have been checked.
Use bisect --extend to continue the bisection from
the common ancestor, 882826199076.

This iteration took 0.706 seconds to run.

Oops! We didn't test rev fe14647a422d, a parent of the blamed revision! Let's do that now.
We did not test rev fe14647a422d because it is not a descendant of either 51b428be6213 or c8288d0c7a15.
Rev fe14647a422d: Found cached shell...
Testing... [Uninteresting] It didn't crash. (0.158 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 fe14647a422d was also good!

Bisect blamed the merge because our initial range did not include one
of the parents.
The common ancestor of fe14647a422d and 51b428be6213 is 882826199076.
Rev 882826199076: Found cached shell...
Testing... Exit status: CRASHED signal 11 (SIGSEGV) (0.136 seconds)
bad (interesting) 
Consider re-running autoBisect with -s 882826199076 -e a1199e0dd68b
in a configuration where earliestWorking is before the common ancestor.

Comment 5

[Andrew McCreight [:mccr8]]

Opt crash in comment 2 is very GGCish, so Terrence or Jon may be interested.

Comment 6

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

Eric, is bug 997894 likely related?

Comment 7

[Andrew McCreight [:mccr8]]

In another bug, Eric was saying there was a case where he landed a bug with some GC hazards, then it got backed out, then relanded with the hazards fixed.  This seems supported by comment 4.

Comment 8

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

Yep, sounds possible - I thought I read that too.

Comment 9

[Eric Faust [:efaust]]

Yeah, this does not reproduce on tip, and is consistent with that behavior. I'm calling this a win.

Comment 10

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

I'm optimistically assuming that the backout reached Aurora as well and am setting status-firefox32 accordingly. Please verify that, though :)

Comment 12

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

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #11)
> I'm optimistically assuming that the backout reached Aurora as well and am
> setting status-firefox32 accordingly. Please verify that, though :)

Yes, it did.

(One of the backouts in bug 997894 comment 11 is at: http://hg.mozilla.org/releases/mozilla-aurora/rev/0785e0d17abd - subsequent comments in that bug were the follow-up fixes.)