695896 - TI: "Assertion failure: [infer failure] Missing type pushed 0: [0xf6c032c0], "

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

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

Attachment: more information, and stack

evalcx("(function (){var x=/x/;print(x)})()", newGlobal("same-compartment"))

asserts js debug shell on JM changeset 311fdb9b38b7 with -m, -a and -n at Assertion failure: [infer failure] Missing type pushed 0: [0xf6c032c0],

Comment 1

[Brian Hackett [Laid off!]]

Locking because this also shows up on m-c and mismatches between inferred and actual information are generally bad.  Regression from bug 692657 so only affects Firefox 10, patch in a minute.

Comment 2

[Brian Hackett [Laid off!]]

Attachment: patch

When regexp objects are created while parsing a cross-global eval call, they get parented to the caller's global rather than the callee's global, so there is a mismatch even in compileAndGo code.  This shouldn't be happening; it's bug 631135, which won't get fixed until compartment-per-global.  So this fix is a band-aid, to catch such cases in the compiler and make sure compiled code is consistent with the inferred types.

Comment 3

[Jeff Walden [:Waldo]]

I'm told on IRC that "parented" refers to both parent chain and to prototype chain, but that doesn't seem to match what I see here with a cross-global eval call, either same-compartment or different-compartment:

[jwalden@wheres-wally src]$ ~/moz/inbound/js/src/dbg/js
js> var g = newGlobal("same-compartment");
js> Object.getPrototypeOf(g.eval("/foo/")) === g.RegExp.prototype
true
js> Object.getPrototypeOf(g.eval("/foo/")) === RegExp.prototype
false
js> var g2 = newGlobal("new-compartment");
js> Object.getPrototypeOf(g2.eval("/foo/")) === g2.RegExp.prototype
true
js> Object.getPrototypeOf(g2.eval("/foo/")) === RegExp.prototype
false

What am I missing or doing wrong in this testcase?

(I specifically ask because I know we use the global of the callee in eval and in Function when compiling up the eval or function script, so I would think things actually do get parented correctly in this particular case.)

Comment 4

[Brian Hackett [Laid off!]]

When the /foo/ gets executed, the interpreter clones the regexp wrt the active global, which is correct, so the mismatch is symptomless.  The bug here is that the compiler assumed the (uncloned) regexp literal had a prototype matching that of the compileAndGo global for the script, and generated code producing one with the wrong parent/proto.

I tested with inner functions in eval too and that seemed to work, so the callee global seems to get used correctly in those cases.  The parent passed in to the compiler is not used when constructing regexp literals, it goes through RegExp::create and on to NewBuiltinClassInstance which gets the scope from the stack.  I think the construction of object and array literals has a similar problem (though that isn't problematic for TI).

Comment 5

[Jeff Walden [:Waldo]]

Ah, so the problem is with the primordial RegExp object created for a literal by the parser at parse time, the one never itself handed out to script.  Or so I understand you.  Perhaps there should be no such object, and the parser should create just a RegExpPrivate that would have to be used at runtime to create the fresh RegExp object.

Comment 6

[Chris Leary [:cdleary] (not checking bugmail)]

Comment on attachment 570046 [details] [diff] [review]
patch

Brian says that "globalObj is non-NULL" is equivalent to "script is compile-and-go" in the mjit compiler, so this looks good to me. Can't wait for compartment per global to fix all these things.

Comment 7

[Johnny Stenback (:jst)]

Guessing at sg:critical here, but if that's not the case feel free to explain what it should be. Thanks!

Comment 8

[Brian Hackett [Laid off!]]

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

Comment 9

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/mozilla-central/rev/e05e46646dc3

Comment 10

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.