862357 - IonMonkey: Assertion failure: ins->type() == MIRType_Value, at ion/MIR.h:1833 or Crash [@ getInterval]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision 1d9c510b3742 (run with --ion-eager):


function TestCase(e, a)
  this.passed = (e == a);
function reportCompare (expected, actual) {
  var expected_t = typeof expected;
  var actual_t = typeof actual;
  if (expected_t != actual_t)
    printStatus();
  new TestCase(expected, actual);
}
var expect = '';
reportCompare(expect, '');
try {
  test();
} catch(exc1) {}
function test() {
  var { expect }  = '';
  for (var a = 1; a < 2; ++a)
    reportCompare(expect, '');
}
test();

Comment 1

[Christian Holler (:decoder)]

Crash trace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000747fef in getInterval (i=0, this=<optimized out>) at js/src/ion/LiveRangeAllocator.h:404
404             return intervals_[i];
(gdb) bt
#0  0x0000000000747fef in getInterval (i=0, this=<optimized out>) at js/src/ion/LiveRangeAllocator.h:404
#1  js::ion::LiveRangeAllocator<js::ion::LinearScanVirtualRegister>::buildLivenessInfo (this=<optimized out>) at js/src/ion/LiveRangeAllocator.cpp:699
#2  0x0000000000740878 in js::ion::LinearScanAllocator::go (this=0x7fffffffc670) at js/src/ion/LinearScan.cpp:1137
#3  0x00000000006e40e7 in js::ion::GenerateLIR (mir=0xcc4520) at js/src/ion/Ion.cpp:1130
#4  0x00000000006e75ee in CompileBackEnd (mir=0xcc4520, maybeMasm=<optimized out>) at js/src/ion/Ion.cpp:1210
#5  compile (autoDelete=<synthetic pointer>, builder=0xcc4520, this=<optimized out>, graph=<optimized out>) at js/src/ion/Ion.cpp:1403
#6  js::ion::IonCompile<js::ion::SequentialCompileContext> (cx=0xc1b300, script=0x7ffff6738380, fun=(JSFunction *) 0x7ffff67470c0 [object Function "test"], osrPc=0x0, constructing=false, compileContext=...)
    at js/src/ion/Ion.cpp:1343
#7  0x00000000006e77c8 in js::ion::Compile<js::ion::SequentialCompileContext> (cx=<optimized out>, script=0x7ffff6738380, fun=..., osrPc=<optimized out>, constructing=<optimized out>, compileContext=...)
    at js/src/ion/Ion.cpp:1574
#8  0x00000000006e7bfa in js::ion::CanEnter (cx=0xc1b300, script=0x7ffff6738380, fp=..., isConstructing=false) at js/src/ion/Ion.cpp:1684
#9  0x00000000004bf502 in js::RunScript (cx=0xc1b300, fp=0x7ffff69d50b8) at js/src/jsinterp.cpp:321
#10 0x00000000004bfa05 in js::InvokeKernel (cx=0xc1b300, args=..., construct=js::NO_CONSTRUCT) at js/src/jsinterp.cpp:422
#11 0x00000000004c0070 in Invoke (construct=js::NO_CONSTRUCT, args=..., cx=0xc1b300) at js/src/jsinterp.h:135
#12 js::Invoke (cx=0xc1b300, thisv=..., fval=..., argc=0, argv=<optimized out>, rval=0x7fffffffd2f0) at js/src/jsinterp.cpp:455
#13 0x0000000000860104 in js::ion::DoCallFallback (cx=0xc1b300, frame=0x7fffffffd378, stub=0xc147b8, argc=0, vp=0x7fffffffd338, res=...) at js/src/ion/BaselineIC.cpp:6320
#14 0x00007ffff7e143fc in ?? ()
[...]
#24 0x0000000000000000 in ?? ()
(gdb) x /i $pc
=> 0x747fef <js::ion::LiveRangeAllocator<js::ion::LinearScanVirtualRegister>::buildLivenessInfo()+2895>:        mov    (%rax),%rax
(gdb) info reg rax
rax            0x0      0


Might call this a classic already, given that we fixed already two bugs with exactly the same signature ;) Marking s-s because these previous bugs were s-s.

Comment 2

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, result:
Due to skipped revisions, the first bad revision could be any of:
changeset:   122584:b831500ca4be
user:        David Anderson
date:        Thu Feb 21 13:52:09 2013 -0800
summary:     Prevent GC from occuring during IC linking (bug 837714, r=bhackett).

changeset:   122585:437c955ff06d
user:        Nicolas B. Pierron
date:        Wed Jan 30 07:41:01 2013 -0800
summary:     Bug 796114 - Inline with type-checked arguments. r=h4writer

changeset:   122586:5054f997ef77
user:        Gregory Szorc
date:        Thu Feb 21 14:11:54 2013 -0800
summary:     Bug 841074 - Statically declare fields on FHR measurements; r=rnewman

changeset:   122587:6c126d076b0d
user:        Phil Ringnalda
date:        Thu Feb 21 14:26:04 2013 -0800
summary:     Back out b831500ca4be (bug 837714) for bustage

This iteration took 12.713 seconds to run.

Comment 3

[Hannes Verschore [:h4writer]]

Attachment: Patch

Comment 4

[Nicolas B. Pierron [:nbp]]

Comment on attachment 738252 [details] [diff] [review]
Patch

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

Thanks for taking care of these bugs :)

Comment 5

[Hannes Verschore [:h4writer]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0e7c67a08b56

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/0e7c67a08b56

Comment 7

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 8

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

Hannes,

This needed sec-approval+ to go in since it affects trunk *and* Aurora. See https://wiki.mozilla.org/Security/Bug_Approval_Process. Security issues can only go in without approval if they *only* affect trunk.

Please create a patch for Aurora and nominate it for that branch since this is a sec-critical that we don't want to ship when Firefox 22 goes out.

Comment 9

[Hannes Verschore [:h4writer]]

Comment on attachment 738252 [details] [diff] [review]
Patch

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

User impact if declined: 
Possible zero crashes in very specific created scripts. Not sure if it is possible to trigger in browser.

Testing completed (on m-c, etc.): m-i: a day, m-c: 1 hour

Risk to taking this patch (and alternatives if risky): 
No risk

String or IDL/UUID changes made by this patch:
/

Comment 10

[Hannes Verschore [:h4writer]]

Comment on attachment 738252 [details] [diff] [review]
Patch

When landing this, we probably want to land bug 863261 at the same time. I will request approval again, when other bug lands. (Should happen quickly)

Comment 11

[Hannes Verschore [:h4writer]]

Comment on attachment 738252 [details] [diff] [review]
Patch

Sorry about the spam, these bugs look to much alike. And I was commenting the wrong one. This request should stay.

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

User impact if declined: 
Possible zero crashes in very specific created scripts. Not sure if it is possible to trigger in browser.

Testing completed (on m-c, etc.): m-i: a day, m-c: a day

Risk to taking this patch (and alternatives if risky): 
No risk

String or IDL/UUID changes made by this patch:
/

Comment 12

[bhavana bajaj [:bajaj]]

(In reply to Hannes Verschore [:h4writer] from comment #11)
> Comment on attachment 738252 [details] [diff] [review]
> Patch
> 
> Sorry about the spam, these bugs look to much alike. And I was commenting
> the wrong one. This request should stay.

So we do not need 863261 when uplifting this ?
> 
> [Approval Request Comment]
> Bug caused by (feature/regressing bug #): bug 796114
> 
> User impact if declined: 
> Possible zero crashes in very specific created scripts. Not sure if it is
> possible to trigger in browser.
> 
> Testing completed (on m-c, etc.): m-i: a day, m-c: a day
> 
> Risk to taking this patch (and alternatives if risky): 
> No risk
> 
> String or IDL/UUID changes made by this patch:
> /

Comment 13

[Hannes Verschore [:h4writer]]

No, this doesn't depend on #863261. This one is on its own.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

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

Comment 15

[u279076]

Marking status-firefox23:verified based on comment 7.