1029130 - Assertion failure: IsCompatibleLIRCoercion(def->type(), as->type()), at jit/shared/Lowering-shared-inl.h:195 or Crash on Heap with invalid read

Status: VERIFIED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision 366b5c0c02d3 (run with --fuzzing-safe):


var PointType2 = new TypedObject.StructType({ y: TypedObject.float64 });
function xPlusY(p) {
  return p.x + p.y;
}
function xPlusYTweak(p = x ? Math.y : x)  {
  return xPlusY(p);
}
var N = 100;
for (var i = 0; i < N; "IQD") {
  obj = new PointType2({x: i, y: i+1});
  xPlusYTweak(obj)
}

Comment 1

[Christian Holler (:decoder)]

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

Comment 2

[Christian Holler (:decoder)]

This crashes on the heap with an invalid read from a bogus address:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7fdf03b in ?? ()
#0  0x00007ffff7fdf03b in ?? ()
[...]
#7  0x00007ffff575a680 in ?? ()
rax     0xf5846770      -1125900082714768
=> 0x7ffff7fdf03b:      mov    0x30(%rax),%r11



Marked s-s and sec-critical based on that.

Comment 3

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/b2ed6214694f
user:        Nicholas D. Matsakis
date:        Mon Feb 10 14:48:51 2014 -0500
summary:     Bug 898356 Part 4 -- Check for neutered typed object unless the check is covered by a length check r=jandem

This iteration took 234.629 seconds to run.

Comment 4

[Christian Holler (:decoder)]

Needinfo from nmatsakis based on comment 3 :)

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

Jan, since Nick is away for a bit would you be able to confirm comment 3?

Comment 6

[Jan de Mooij [:jandem]]

On x86 I get this assertion failure in LIRGeneratorShared::use:

  JS_ASSERT(mir->type() != MIRType_Value);

It looks like MNeuterCheck has a MIRType_Value operand but it uses useRegister. It probably needs an object type policy.

Niko, can you please comment on this bug or forward it to somebody else? These asserts make it harder for the fuzzers to find other bugs.

Comment 7

[Al Billings [:abillings - ex-MoCo]]

Any updates on this?

Comment 8

[Niko Matsakis [:nmatsakis]]

So I investigated the problem. I am unclear on where exactly this bug is. The `MDefinition` in question is a phi that starts out as an object and is later changed to a value as part of type adjustment. I was under the (false?) impression that code could rely on the type etc of an `MDefinition` not to change. If this is false, I think there are a number of places that will need object policies.

Comment 9

[Andrew McCreight [:mccr8]]

This looks like it is a trunk-only thing.

Comment 10

[Niko Matsakis [:nmatsakis]]

Attachment: Bug1029130.diff

Add object policy to MNeuterCheck. One question is: I was unable to produce a test that reproduced with fewer than 10000 iterations, even with --ion-eager. I'm actually not quite sure why this is. Any suggestions?

Comment 11

[Jan de Mooij [:jandem]]

Comment on attachment 8469624 [details] [diff] [review]
Bug1029130.diff

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

(In reply to Niko Matsakis [:nmatsakis] from comment #10)
> One question is: I was unable to produce
> a test that reproduced with fewer than 10000 iterations, even with
> --ion-eager. I'm actually not quite sure why this is. Any suggestions?

Did you try --ion-eager --ion-offthread-compile=off? Parallel compilation can take a while. (We run jit-tests with these flags as part of jit_test.py --tbpl)

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9c1418c26c20

Comment 13

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 14

[Niko Matsakis [:nmatsakis]]

(In reply to Jan de Mooij [:jandem] from comment #11)
> Did you try --ion-eager --ion-offthread-compile=off? Parallel compilation
> can take a while. (We run jit-tests with these flags as part of jit_test.py
> --tbpl)

I did try that, I believe.