919949 - Assertion failure: hasScript(), at ../../jsfun.h:299 or Crash [@ JSScript::markChildren]

Status: RESOLVED DUPLICATE of bug 919140

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision 1fda74e33e06 (threadsafe build, run with --fuzzing-safe --ion-eager --thread-count=2 --ion-parallel-compile=on):


var lfcode = new Array();
lfcode.push("function $ERROR(message) { if ( !isFinite(year) || !isFinite(month) || !isFinite(date)) {  } }");
lfcode.push("gczeal(4);");
lfcode.push("function iterate(x) { while (x == 2046) $ERROR('');}try { Array.buildPar(2048, iterate); } catch(exc1) {}");
lfcode.push("gczeal(4,10);");
lfcode.push("function $ERROR(message) { if ( !isFinite(year) || !isFinite(month) || !isFinite(date)) {  }}");
var lfRunTypeId = -1;
while (true) {
	var file = lfcode.shift(); if (file == undefined) { break; }
        loadFile(file)
    }
function loadFile(lfVarx) {
    try {
        if (lfVarx.substr(-3) != ".js") {
            switch (lfRunTypeId) {
                default: evaluate(lfVarx, { noScriptRval : true }); break;
            }
        }
    } catch (lfVare) {}
}

Comment 1

[Christian Holler (:decoder)]

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

Comment 2

[Daniel Veditz [:dveditz]]

any idea on a regression range?

Comment 3

[Christian Holler (:decoder)]

(In reply to Daniel Veditz [:dveditz] from comment #2)
> any idea on a regression range?

This would require a manual bisection with a threadsafe build which JSBugMon doesn't support. Maybe gkw can help with that?

Comment 4

[Nicolas B. Pierron [:nbp]]

This sounds like a problem linked to the lazy JSOP_LAMBDA compilations.  Where we might access a script from another thread. Does Bug 901178 last patch (adding assertions) catch anything here?

Comment 5

[Brian Hackett [Laid off!]]

Decoder, can you attach a stack?

Comment 6

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

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   http://hg.mozilla.org/mozilla-central/rev/72681e08a35d
user:        Brian Hackett
date:        Fri Sep 20 07:43:46 2013 -0600
summary:     Bug 918116 - Don't delazify scripts during Ion compilation, r=jandem.

Brian, is bug 918116 a likely cause?

Comment 7

[Brian Hackett [Laid off!]]

I can't reproduce, but this should be trivial to figure out if someone attaches a stack.

Comment 8

[Andrew McCreight [:mccr8]]

Needinfoing for a stack.

Comment 9

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

Attachment: stack

I've attached the stack from m-c rev a2c31dc69ab3.

Comment 10

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

autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   http://hg.mozilla.org/mozilla-central/rev/732581f15f34
user:        Brian Hackett
date:        Wed Sep 25 13:14:21 2013 -0600
summary:     Bug 919140 - Watch for lazy scripts in AddPossibleCallees, r=jandem.

However, bug 919140 may have fixed this - does this seem possible?

Comment 11

[Brian Hackett [Laid off!]]

Yeah, this bug is fixed (and was never a security risk, as it depends on PJS).

Comment 13

[Christian Holler (:decoder)]

(In reply to Brian Hackett (:bhackett) from comment #11)
> Yeah, this bug is fixed (and was never a security risk, as it depends on
> PJS).

What exactly does it depend on that's not yet shipped? I thought parallel compilation was on by default by now.

Comment 14

[Brian Hackett [Laid off!]]

(In reply to Christian Holler (:decoder) from comment #13)
> (In reply to Brian Hackett (:bhackett) from comment #11)
> > Yeah, this bug is fixed (and was never a security risk, as it depends on
> > PJS).
> 
> What exactly does it depend on that's not yet shipped? I thought parallel
> compilation was on by default by now.

Parallel JS, which is activated by the call to Array.buildPar, is I think only turned on in nightlies and is separate from parallel compilation (which is on by default everywhere).

Comment 15

[Andrew McCreight [:mccr8]]

Nightly-only security bugs are still tracked as security-sensitive bugs.

Comment 16

[Christian Holler (:decoder)]

Re-adding the security rating, but leaving the bug open now because only nightlies were affected and the bug is fixed there.