714600 - Assertion failure: [infer failure] Missing type pushed 0: [0xf6c001c0], at jsinfer.cpp:349

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following test asserts on mozilla-central revision d98fbf3cbd71 (options -m -n):


var UBound = 0;
var actual = '';
var actualvalues = [];
var expect= '';
var expectedvalues = [];
function addThis() {
  actualvalues[UBound] = actual;
  expectedvalues[UBound] = expect;
  UBound++;
}
function testLengthOnNonNativeProto() {
  var o2 = {};
  o2.__proto__ = [];
  for (var j = 0; j < 5; (({})[addThis()]))
    o2.length;
}
assertEq(testLengthOnNonNativeProto(), "no assertion");



S-s due to previous infer failures being security-relevant.

Comment 1

[Brian Hackett [Laid off!]]

Attachment: patch

TI bug involving mutable proto.  When the prototype of an object is dynamically mutated, the object's type changes and we mark all type sets containing the object as unknown.  If a GC occurs then all type sets in the script are purged, along with the original type of the object (if it is not live), forgetting the information that objects with that type have had their prototypes mutated.  If we reanalyze the script after the GC, information about the prototype change has been lost and accesses on the initializer objects are treated as if they still had their original prototype.  This fix marks initializer opcodes as JOF_TYPESET, so that persistent type sets retain information about initializers which have seen their prototypes mutated.

Comment 2

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1a8a06e6c634

Comment 3

[Brian Hackett [Laid off!]]

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

[Approval Request Comment]
User impact if declined: Potential security exploit
Risk to taking this patch (and alternatives if risky): Minimal, this only has an effect when an absurd language corner case is being used (mutable prototypes).

Comment 4

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/mozilla-central/rev/1a8a06e6c634

Comment 5

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/a0027a963235
https://hg.mozilla.org/releases/mozilla-beta/rev/139e57394142

Comment 6

[u279076]

No assertion reproduced with the test in comment 0 with js-shell built from today's mozilla-beta.

Comment 7

[u279076]

Any tips on how I can verify this? I tried loading the test in comment 0 using the 2012-01-01 linux-x64 jsshell but could not reproduce the assertion.

Comment 8

[Christian Holler (:decoder)]

(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #7)
> Any tips on how I can verify this? I tried loading the test in comment 0
> using the 2012-01-01 linux-x64 jsshell but could not reproduce the assertion.

What branch are we talking about? :)

Comment 9

[u279076]

(In reply to Christian Holler (:decoder) from comment #8)
> (In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #7)
> > Any tips on how I can verify this? I tried loading the test in comment 0
> > using the 2012-01-01 linux-x64 jsshell but could not reproduce the assertion.
> 
> What branch are we talking about? :)

I was trying to test this on mozilla-central so I know I can reproduce the original issue before verifying on Beta.

Comment 10

[Christian Holler (:decoder)]

Just testing something :)

Comment 11

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug does not reproduce on branch mozilla-aurora (tried revision 883536e3b5da).
JSBugMon: The testcase found in this bug does not reproduce on branch mozilla-beta (tried revision e4ed83ba6eb9).

Comment 12

[Christian Holler (:decoder)]

The last comment means the bot successfully reproduced the issue on mozilla-central with the specified revision in comment 0, but it was not able to reproduce the issue on beta or aurora tip.

Comment 13

[Mihaela Velimiroviciu (:mihaelav)]

Ubuntu 11.04 32bit:

I built jsshell for the latest beta release (12.0b4, rev 9bfe6330d055) and ran the test from comment #0: the test ran for several minutes until it went out of memory.

Is this expected?

Comment 14

[Christian Holler (:decoder)]

(In reply to Mihaela Velimiroviciu [QA] from comment #13)
> 
> Is this expected?


Very likely, yes. My fuzz testcases usually don't have a "useful" behavior once they are fixed. Some just loop infinitely long, others go oom, again others just throw some exception, but all of that is fine usually. Note that on Linux, per comment 11, this has been verified fixed on aurora and beta with the given revisions :) Or do you need to verify for a specific revision?

Comment 15

[Mihaela Velimiroviciu (:mihaelav)]

(In reply to Christian Holler (:decoder) from comment #14)

Verification on any Firefox 12.0 beta revision is ok.
Changing the flag status-firefox12 to verified.
Thank you!

Comment 16

[Jesse Ruderman]

Decoder, it would be nice if you tried to remove/shorten the iloops before posting. It makes bisecting and verifying easier :)

Comment 17

[u279076]

Verified fixed in Firefox 10 and ESR:10.

Comment 18

[Christian Holler (:decoder)]

Even without iloop, this test takes very long to complete, not taking into the testsuite.