932284 - Assertion failure: IsBaselineEnabled(cx), at jit/Bailouts.cpp:77

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision 518f5bff0ae4 (run with --ion-eager):


function foo() {
  var func = []
  for (var n = 0; n < 2; ++n) {
    setJitCompilerOption("baseline.enable", n);
    func[n]();
  }
} foo();

Comment 1

[Christian Holler (:decoder)]

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

Comment 2

[Jan de Mooij [:jandem]]

Yeah we shouldn't allow disabling the Baseline JIT while there's JIT code on the stack I think.

Comment 3

[Nicolas B. Pierron [:nbp]]

(In reply to Jan de Mooij [:jandem] from comment #2)
> Yeah we shouldn't allow disabling the Baseline JIT while there's JIT code on
> the stack I think.

This problem will also appear if somebody flip the flag in about:config.

Comment 4

[Nicolas B. Pierron [:nbp]]

(In reply to Nicolas B. Pierron [:nbp] from comment #3)
> (In reply to Jan de Mooij [:jandem] from comment #2)
> > Yeah we shouldn't allow disabling the Baseline JIT while there's JIT code on
> > the stack I think.
> 
> This problem will also appear if somebody flip the flag in about:config.

Also, note that being able to flip baseline on/off will give the ability to fuzz more.  Especially doing even more differential testing.

Comment 5

[Jesse Ruderman]

Yeah, I want to be able to control future compilation for differential testing.  I don't care whether already-running code stays in baseline.

Comment 6

[Christian Holler (:decoder)]

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

Comment 7

[Christian Holler (:decoder)]

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

Comment 8

[Christian Holler (:decoder)]

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

The first good revision is:
changeset:   http://hg.mozilla.org/mozilla-central/rev/636620b3af0a
user:        Brian Hackett
date:        Tue Oct 29 16:10:59 2013 -0600
summary:     Bug 930048 - Remove need to read objects directly when optimizing singleton accesses, r=jandem.

This iteration took 381.486 seconds to run.

Comment 9

[Christian Holler (:decoder)]

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

Comment 10

[Christian Holler (:decoder)]

This bug still reproduces for me all the time. Example testcase:


try {
for (var n = 0; n < 4; ++n) {
    setJitCompilerOption("baseline.enable", n & 1);
        func[n]();
}
} catch(exc0) {}
const root = newGlobal();
root.eval("this.dbg = new Debugger()");
root.dbg.addDebuggee(this);


Or this one on the ARM simulator:


var method_A = function() {}
var method_B = function() {}
var method_C = function() {}
var method_D = function() {}
var func = [method_A, method_B, method_C, method_D]
for (var n = 0; 16      ; ++n) {
    setJitCompilerOption("baseline.enable", n & 1);
        func[n]();
}



All involving setJitCompilerOption.

Jan, could you maybe figure out who's the right person to ask about this? This is probably a shell-only/debug-only fix, but it would lower the crash rates I'm seeing in the fuzzer.

Comment 11

[Jan de Mooij [:jandem]]

Attachment: Patch

Throw an exception when we try to disable the JITs with JIT code on the stack.

Comment 12

[Nicolas B. Pierron [:nbp]]

Comment on attachment 8487818 [details] [diff] [review]
Patch

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

This patch sounds fine for fuzzers, but what is the fate of:

http://dxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCJSRuntime.cpp#1497

for example if what would happen if a user change the preference under an interruption callback?
Maybe we could have a mode for the jsapi function which fails silently.

Comment 13

[Jan de Mooij [:jandem]]

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

(In reply to Nicolas B. Pierron [:nbp] from comment #12)
> for example if what would happen if a user change the preference under an
> interruption callback?
> Maybe we could have a mode for the jsapi function which fails silently.

Only devs or power users toggle the prefs and it hasn't been a problem so far; I think it's fine to leave this for now.

Comment 14

[Phil Ringnalda (:philor)]

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