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

RESOLVED FIXED in mozilla35

Status

()

--
critical
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: decoder, Assigned: jandem)

Tracking

(Blocks: 1 bug, {assertion, testcase})

Trunk
mozilla35
x86_64
Linux
assertion, testcase
Points:
---

Firefox Tracking Flags

(firefox27 affected)

Details

(Whiteboard: [jsbugmon:])

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

5 years ago
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();
(Reporter)

Comment 1

5 years ago
Created attachment 823996 [details]
[crash-signature] Machine-readable crash signature
(Assignee)

Comment 2

5 years ago
Yeah we shouldn't allow disabling the Baseline JIT while there's JIT code on the stack I think.
Flags: needinfo?(nicolas.b.pierron)
(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.
Flags: needinfo?(nicolas.b.pierron)
(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

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

Comment 6

5 years ago
Created attachment 827705 [details]
[crash-signature] Machine-readable crash signature
Attachment #823996 - Attachment is obsolete: true
(Reporter)

Updated

5 years ago
Whiteboard: [jsbugmon:update]
(Reporter)

Updated

5 years ago
Whiteboard: [jsbugmon:update] → [jsbugmon:update,ignore]
(Reporter)

Comment 7

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

Updated

5 years ago
Whiteboard: [jsbugmon:update,ignore] → [jsbugmon:bisectfix]
(Reporter)

Updated

5 years ago
Whiteboard: [jsbugmon:bisectfix] → [jsbugmon:]
(Reporter)

Comment 8

5 years ago
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.
(Reporter)

Comment 9

5 years ago
Created attachment 8339560 [details]
[crash-signature] Machine-readable crash signature
Attachment #827705 - Attachment is obsolete: true
(Reporter)

Updated

5 years ago
status-firefox27: --- → affected
Assignee: general → nobody
(Reporter)

Comment 10

4 years ago
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.
Flags: needinfo?(jdemooij)
(Assignee)

Comment 11

4 years ago
Created attachment 8487818 [details] [diff] [review]
Patch

Throw an exception when we try to disable the JITs with JIT code on the stack.
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Attachment #8487818 - Flags: review?(nicolas.b.pierron)
Flags: needinfo?(jdemooij)
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.
Attachment #8487818 - Flags: review?(nicolas.b.pierron) → review+
(Assignee)

Comment 13

4 years ago
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.
https://hg.mozilla.org/mozilla-central/rev/a5caeacb3411
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
You need to log in before you can comment on or make changes to this bug.