884369 - Assertion failure: hasBaselineScript(), at ../jsscript.h:699 or Crash [@ js::ion::BaselineScript::nativeCodeForPC] or Crash [@ js::ion::BaselineScript::icEntryFromPCOffset]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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


gczeal(2);
function testScatter() {
  var shape = [5];
  for (var i = 0; i < 1000; ++i) {
    shape.push(1);
    var p = new ParallelArray(shape, function(k) { return k; });
    var r = p.scatter([0,1,0,3,0e26 ], 9, function (a,b) { return a+shape ; }, 10);
  }
}
testScatter();

Comment 1

[Christian Holler (:decoder)]

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

Comment 2

[Christian Holler (:decoder)]

Marked s-s because this involves gczeal.

Comment 3

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

I also saw this on rev 36da3cb92193 but it might have been fixed by the time 1790f40f71f0 landed (not the smallest regression window, I was testing on inbound).

Comment 4

[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/48afaae197ab
user:        Gavin Sharp
date:        Fri May 31 14:56:48 2013 -0700
summary:     Bug 878291: define RELEASE_BUILD/NIGHTLY_BUILD in the js configure too, r=ted

This iteration took 306.992 seconds to run.

Comment 5

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

Never mind me, turns out they are different testcases and the testcase in comment 0 still reproduces for me on rev 1790f40f71f0.

Comment 6

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 8ea92aeab783).

Comment 7

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 8ea92aeab783).
JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   http://hg.mozilla.org/mozilla-central/rev/3efe3f3d2c25
user:        Jan de Mooij
date:        Wed Jun 19 19:10:04 2013 +0200
summary:     Bug 882111 - Don't push an interpreter frame when calling into the JITs. r=djvj

This iteration took 297.906 seconds to run.

Comment 8

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

Jan, is bug 882111 a possible fix?

Comment 9

[Jan de Mooij [:jandem]]

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #8)
> Jan, is bug 882111 a possible fix?

Unlikely, it's probably hiding this bug. Does anybody have an updated testcase maybe?

@nmatsakis, shu: looking at the testcase, it's probably a PJS bug.

Comment 10

[Shu-yu Guo [:shu]]

Looking at it now, it seems like all the jitcode is discarded while the function is active on the stack. Not sure how that could be, yet...

Comment 11

[Shu-yu Guo [:shu]]

Attachment: fix

Bug was due to us pushing the wrong callee in poly inline dispatch. Should've pushed the cloned version whereas we were pushing the original.

Comment 12

[Shu-yu Guo [:shu]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/08f43331a642

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/08f43331a642

Comment 14

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 15

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

This looks to affect ESR24. Can we get this fixed there?

Comment 16

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

Setting needinfo so I can perhaps get an ESR24 patch in time for the release?

Comment 17

[Shu-yu Guo [:shu]]

This is a bug in Ion's interaction with callsite cloning. While the buggy code in question exists on ESR24, the only user of callsite cloning is PJS. PJS is ifdef'd out in all branches except Nightly, so there's no way to trigger this.

Comment 18

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

Thanks!