1001382 - Assertion failure: !val.isMagic(), at jit/BaselineIC.cpp:1189

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Christian Holler (:decoder)]

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


var i = 0;
var expectedmatch = '';
var expectedmatches = new Array();
addThis();
expectedmatch = null;
addThis();
function addThis() {
  Array(-2147483648, -2147483648);
  expectedmatches[i] = expectedmatch;
}

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/d34458e80bcb
user:        Shu-yu Guo
date:        Thu Apr 24 01:59:36 2014 -0700
summary:     Bug 716647 - Part 1: Introduce JS_OPTIMIZED_OUT magic for optimized out slots and teach Debugger about them. (r=jandem)

This iteration took 1.239 seconds to run.

Comment 3

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

Shu-yu, our fuzzers are hitting this too - is bug 716647 a likely regressor?

Comment 4

[Shu-yu Guo [:shu]]

Attachment: Don't monitor optimized out values.

Baseline unconditionally monitors values, even dead ones, after a bailout from
Ion. Don't bother.

Jan, are there other places in baseline where we try to monitor a value after
bailing out of Ion?

Comment 5

[Jan de Mooij [:jandem]]

Comment on attachment 8417807 [details] [diff] [review]
Don't monitor optimized out values.

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

(In reply to Shu-yu Guo [:shu] from comment #4)
> Jan, are there other places in baseline where we try to monitor a value after
> bailing out of Ion?

I think this patch covers everything.

We could also fix this in BaselineBailouts (not enter the monitor chain in this case), but that code is complicated enough and the extra check in DoTypeMonitorFallback shouldn't really matter.

Comment 6

[Shu-yu Guo [:shu]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/22412f279972

Comment 7

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/22412f279972