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

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Christian Holler (:decoder)]

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 });

Comment 1

[Christian Holler (:decoder)]

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

Comment 2

[Christian Holler (:decoder)]

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.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: debugging info from hitting assertion on Zimbra

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

Comment 4

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

Hannes, is bug 953164 a likely regressor? This seems to be showing up in the browser as per comment 3.

Comment 5

[Hannes Verschore [:h4writer]]

(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

Comment 6

[Hannes Verschore [:h4writer]]

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, ...)

Comment 7

[Hannes Verschore [:h4writer]]

So I had to add "--ion-parallel-compile=off" off course, thanks decoder

Comment 8

[Hannes Verschore [:h4writer]]

Attachment: Disable this optimization when resultTypeSet is unknown

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.

Comment 9

[Jan de Mooij [:jandem]]

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?

Comment 10

[Hannes Verschore [:h4writer]]

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

Comment 11

[Hannes Verschore [:h4writer]]

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:
/

Comment 12

[Ryan VanderMeulen [:RyanVM]]

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

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/eb5fc4360489