Closed Bug 1099224 Opened 10 years ago Closed 10 years ago

Assertion failure: !ion || ion == ((js::jit::IonScript *)0x1), at jsscript.h

Categories

(Core :: JavaScript Engine: JIT, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED
Tracking Status
firefox35 --- unaffected
firefox36 --- verified
firefox-esr31 --- unaffected

People

(Reporter: gkw, Assigned: shu)

References

Details

(Keywords: assertion, regression, testcase)

Attachments

(2 files, 1 obsolete file)

Attached file stack (obsolete) —
var g = newGlobal();
var dbg = new Debugger(g);
g.eval('\
    function f() { \
        throw 1; \
    }\
');
dbg.onExceptionUnwind = function() {};
try {
    g.f();
} catch (e) {}

asserts the following shell intermittently on m-c changeset 64206634959a with --ion-eager at Assertion failure: !ion || ion == ((js::jit::IonScript *)0x1), at js/src/jsscript.h :

https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64-debug/1415967615/jsshell-linux-x86_64.zip

Stack is largely useless since we don't have symbols from tbpl shells.

This was found by combining random jit-tests together with jsfunfuzz. The specific file, which was run with random flag combinations, is:

http://hg.mozilla.org/mozilla-central/file/7f0d92595432/js/src/jit-test/tests/baseline/bug842431-3.js

Assigning to :h4writer as discussed on IRC.

Setting s-s because I don't really know what's going on. Hannes mentioned we might just be executing 0x1 or 0x2 so it *might* just be a null de-ref, but locking till we have confirmation.
Flags: needinfo?(hv1989)
Attached file stack
Attachment #8523044 - Attachment is obsolete: true
Flags: needinfo?(hv1989)
In RecompileBaselineScriptForDebugMode we use setBaselineScript to remove or set a new BaselineScript. In that function we test there is no ionmonkey for that script available. Since that would/could potentially be a bug. (IonMonkey is based upon a baselinescript, so when removing/adjusting the baselinescript we don't allow to be IonMonkey code present.)

Now in this case we hit it when ion == 0x1. Which signifies IonMonkey is compiling offthread. So IIUC we should invalidate/stop compiling the IonMonkey code, before fiddling with the BaselineScript.

@Shu: seems you created this code. Can you have a look?
Flags: needinfo?(shu)
Oops. Mistake in the recent refactoring. Taking.
Assignee: hv1989 → shu
Flags: needinfo?(shu)
Simple fix. Mind taking the review, Hannes?
Attachment #8523197 - Flags: review?(hv1989)
Comment on attachment 8523197 [details] [diff] [review]
Fix cancelling off-thread Ion compiles for scripts going through debug mode OSR.

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

Thanks for the quick patch.
Attachment #8523197 - Flags: review?(hv1989) → review+
(In reply to Shu-yu Guo [:shu] from comment #3)
> Oops. Mistake in the recent refactoring. Taking.

What is the regressor of this issue? (i.e. what branches does this affect?) This is also likely just a null-deref, isn't it?
Flags: needinfo?(shu)
(In reply to Gary Kwong [:gkw] [:nth10sd] GMT+8 after Oct 9 from comment #6)
> (In reply to Shu-yu Guo [:shu] from comment #3)
> > Oops. Mistake in the recent refactoring. Taking.
> 
> What is the regressor of this issue? (i.e. what branches does this affect?)
> This is also likely just a null-deref, isn't it?

The regressor is bug 1032869.

I'm too lazy to figure if it's just a null-deref. There's this cached raw code ptr for the baseline or Ion script on JSScripts for faster calls, which is generally why setting a baseline script on a script that already has an Ion script is wrong.
Flags: needinfo?(shu)
https://hg.mozilla.org/mozilla-central/rev/ca6516a8ca1d
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
JSBugMon: This bug has been automatically verified fixed.
Summary: Assertion failure: !ion || ion == ((js::jit::IonScript *)0x1), at js/src/jsscript.h → Assertion failure: !ion || ion == ((js::jit::IonScript *)0x1), at jsscript.h
Group: core-security
You need to log in before you can comment on or make changes to this bug.