Closed Bug 984830 Opened 6 years ago Closed 6 years ago

Assertion failure: !types->unknown(), at jit/MIR.h:8819

Categories

(Core :: JavaScript Engine: JIT, defect, critical)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla31
Tracking Status
firefox30 --- fixed
firefox31 --- fixed

People

(Reporter: decoder, Assigned: h4writer)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, regression, testcase, Whiteboard: [jsbugmon:update])

Attachments

(3 files)

The following testcase asserts on mozilla-central revision 082761b7bc54 (run with --fuzzing-safe --ion-eager):


function getTestCaseResult(expected, actual) {
  if (actual != expected)
    return Math.abs(actual - expected) <= 1E-10;
}
function InstanceOf(object, constructor) {
  while ( object != null )
    object = object.__proto__;
}
function WorkerBee () {}
function Engineer () {}
Engineer.prototype = new WorkerBee();
var pat = new Engineer();
getTestCaseResult(pat.__proto__.__proto__.__proto__.__proto__ == Object.prototype);
getTestCaseResult(InstanceOf(pat, Engineer));
evaluate("getTestCaseResult( Object.prototype.__proto__ );", { compileAndGo: true });
Whiteboard: [jsbugmon:update,bisect]
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   http://hg.mozilla.org/mozilla-central/rev/9c18da81043e
user:        Hannes Verschore
date:        Thu Feb 13 23:19:15 2014 +0100
summary:     Bug 953164 - IonMonkey: Improve type information at branches, r=jandem

This iteration took 1.019 seconds to run.
In a Linux 64-bit debug build based on eb3a388afab1 (hash local to me
only) which is some local patches on top of a mozilla-central revision
that that I can't tell you due to mercurial repository corruption
(though I still have the repository if you want to try figuring it out).
It's probably a mozilla-central or mozilla-inbound revision from around
March 16, likely f44d993a20de.

I crashed due to the following JS assertion while clicking the "New
Appointment" button in Zimbra.

Assertion failure: !types->unknown(), at /home/dbaron/builds/ssd/mozilla-central/mozilla/js/src/jit/MIR.h:8819
Hannes, is bug 953164 a likely regressor? This seems to be showing up in the browser as per comment 3.
Blocks: 953164
Flags: needinfo?(hv1989)
Keywords: regression
(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #4)
> Hannes, is bug 953164 a likely regressor? This seems to be showing up in the
> browser as per comment 3.

I think so. Gonna investigate further. Thanks
Assignee: nobody → hv1989
Flags: needinfo?(hv1989)
So I'm trying to reproduce, but failing. I tested the revision you gave in 32bit/64bit/debug/debug-optimized builds. Is there any more information you can give, so I can reproduce this locally? (build flags, running flags, machine OS, ...)
Flags: needinfo?(choller)
So I had to add "--ion-parallel-compile=off" off course, thanks decoder
Flags: needinfo?(choller)
I assumed that the whole TypeSet would get cleared, except for the Unknown flag, when we encounter an unknown typeset. Apparently it still contains data, which this optimization tried to optimize for.
Attachment #8400810 - Flags: review?(jdemooij)
Comment on attachment 8400810 [details] [diff] [review]
Disable this optimization when resultTypeSet is unknown

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

Can you add the testcase, or is it too slow?
Attachment #8400810 - Flags: review?(jdemooij) → review+
Comment on attachment 8400810 [details] [diff] [review]
Disable this optimization when resultTypeSet is unknown

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
bug 953164

User impact if declined:
I think it might not make a difference. But I don't want to be proven wrong, especially with such a small and low risk patch.


Testing completed (on m-c, etc.):
landed on m-i yesterday. Fixes the testcase mentioned by taking the old path. The path we used to use before bug 953164. So that path is very well tested and I don't expect any performance degradation.

Risk to taking this patch (and alternatives if risky):
Alternative to 1 line change? Full backout of that bug :P

String or IDL/UUID changes made by this patch:
/
Attachment #8400810 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/bd6042e86711
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Attachment #8400810 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.