873718 - BaselineCompiler: Assertion failure: !JS_IsExceptionPending(cx), at shell/js.cpp

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

Attachment: stack

x = Object.__proto__;
Object.defineProperty(x, "prototype", {
    get: (function() {
        return function() {
            evaluate("", {
                newContext: true,
            })()
        }
    })(),
});
this
(void options('strict_mode'));

asserts js debug shell on m-c changeset ecdfb8bb501e with --no-ti --ion-eager --no-jm at Assertion failure: !JS_IsExceptionPending(cx), at shell/js.cpp

Comment 1

[Christian Holler (:decoder)]

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

Comment 2

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

Strange that autoBisect points to:

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   130388:533d3fb8a7e9
user:        Norbert Lindenberg
date:        Tue Apr 30 16:28:58 2013 -0400
summary:     Bug 866305 - Enable ECMAScript Internationalization API for JavaScript standalone build. r=Waldo, r=glandium

I'm not sure if this is correct.

--enable-more-deterministic is needed to reproduce this bug.

Comment 3

[Jan de Mooij [:jandem]]

Testcase below does not require an --enable-more-deterministic build.

Looks like we're calling into JS under js_InitIntlClass, so autoBisect is probably correct. Forwarding needinfo? to Waldo.

Object.defineProperty(Object.__proto__, "prototype", {
    get: function() {
        (function() {
            evaluate("print(3);", {newContext: true})();
        })()
    }
});
this.toSource();

Comment 4

[Jeff Walden [:Waldo]]

Attachment: Patch and test

function Record() {
    return std_Object_create(null);
}
MakeConstructible(Record);

|new Record()| evaluates |Record.prototype| to create the object returned by default if an object isn't explicitly returned.  By the time Intl stuff is lazily evaluated, that's going to hit |Function.prototype.prototype| if it exists.  Clear out the prototype so that we don't look up the prototype chain for |new|s.

This is going to be a pervasive self-hosting concern for any sort of utility class, implemented in script, that's ever |new|'d.  Record and List are the only such instances now, and List.prototype is already cleared out.

Comment 5

[Jeff Walden [:Waldo]]

Attachment: Slightly different tack, as discussed

It so happens that JSObject::defineProperty doesn't do a lookup (...which actually probably is sort of a bug, in some cases, for some arguments), so there's no second issue here, or the extra test here would have smoked it out.

Comment 6

[Till Schneidereit [:till]]

Comment on attachment 752445 [details] [diff] [review]
Slightly different tack, as discussed

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

It's not pretty, but yes, absolutely.

Thanks for doing this.

Comment 7

[Jeff Walden [:Waldo]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/091d40b0e948

Comment 8

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/091d40b0e948