747926 - Assertion failure: [infer failure] Missing type pushed 0: void, at jsinfer.cpp:352

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following test asserts on mozilla-central revision 17af008937e3 (options -m -a -n):


a = 'a';
b = [,];
exhaustiveSliceTest("exhaustive slice test 1", a);
exhaustiveSliceTest("exhaustive slice test 2", b);
function exhaustiveSliceTest(testname, a){
  x = 0
  var y = 0;
  countHeap();
  for (y=a.length; y + a.length; y--) 
    var b  = a.slice(x,y);
}


This one involves the shell-only function "countHeap", but I don't know if this is a shell-only bug or just revealing a real bug. Maybe related to bug 746150? S-s until triaged.

Comment 1

[Daniel Veditz [:dveditz]]

taking a guess that countHeap() shouldn't affect inference correctness and assigning sg:critical

Comment 2

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

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   86695:fbef6a165cf8
user:        Bill McCloskey
date:        Fri Feb 10 18:32:08 2012 -0800
summary:     Bug 723313 - Stop using conservative stack scanner for VM stack marking (r=luke,bhackett)

Comment 3

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

Marking flags based on regression window in comment 2.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: patch

Here's the scenario:

1. Code sets y to 0.
2. GC happens. y is dead, so we overwrite it with undefined.
3. Code sets y to 1. As an optimization, it doesn't update the type tag. It incorrectly assumes it hasn't changed since step 1.

The easiest thing to do is to leave the type tag alone in step 2 while fixing up any pointers. The only tags we actually need to worry about are object and string. And we can come up with a dummy string and a dummy object as replacements. The only concern is that this code shouldn't cause the dummy object to be leaked. For objects, I used the global as the dummy. Luke says that the stack frame shouldn't outlive its global, so this seems safe.

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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

Comment 8

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 9

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Comment on attachment 619797 [details] [diff] [review]
patch

[Approval Request Comment]
Regression caused by (bug #): bug 723313
User impact if declined: This may cause crashes or be exploitable.
Testing completed (on m-c, etc.): On m-c.
Risk to taking this patch (and alternatives if risky): Low. We used to overwrite a stack slot with a dummy value, now we overwrite it with a slightly different dummy value.
String changes made by this patch: None

Comment 10

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/6114cf84a407
https://hg.mozilla.org/releases/mozilla-beta/rev/7dfc84b36390

Comment 13

[Christian Holler (:decoder)]

A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/bug747926.js.