Last Comment Bug 714600 - Assertion failure: [infer failure] Missing type pushed 0: [0xf6c001c0], at jsinfer.cpp:349
: Assertion failure: [infer failure] Missing type pushed 0: [0xf6c001c0], at js...
Status: VERIFIED FIXED
[sg:critical][qa+:ashughes] [jsbugmon...
: assertion, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Linux
: -- critical (vote)
: mozilla10
Assigned To: Brian Hackett (:bhackett)
:
Mentors:
Depends on:
Blocks: langfuzz
  Show dependency treegraph
 
Reported: 2012-01-02 03:45 PST by Christian Holler (:decoder)
Modified: 2013-03-11 09:04 PDT (History)
11 users (show)
choller: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
wontfix
+
verified
+
verified
+
verified
10+
verified
unaffected


Attachments
patch (4.35 KB, patch)
2012-01-02 10:40 PST, Brian Hackett (:bhackett)
dvander: review+
curtisk: approval‑mozilla‑aurora+
curtisk: approval‑mozilla‑beta+
Details | Diff | Splinter Review

Description Christian Holler (:decoder) 2012-01-02 03:45:47 PST
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 (:bhackett) 2012-01-02 10:40:27 PST
Created attachment 585308 [details] [diff] [review]
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 (:bhackett) 2012-01-05 06:51:46 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/1a8a06e6c634
Comment 3 Brian Hackett (:bhackett) 2012-01-05 06:54:07 PST
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 (:bhackett) 2012-01-06 04:53:46 PST
https://hg.mozilla.org/mozilla-central/rev/1a8a06e6c634
Comment 6 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-03-07 14:10:56 PST
No assertion reproduced with the test in comment 0 with js-shell built from today's mozilla-beta.
Comment 7 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-04-04 09:58:43 PDT
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) 2012-04-04 15:37:28 PDT
(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 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-04-04 15:45:50 PDT
(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) 2012-04-04 16:56:17 PDT
Just testing something :)
Comment 11 Christian Holler (:decoder) 2012-04-04 17:27:36 PDT
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) 2012-04-04 17:30:23 PDT
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) 2012-04-06 05:43:58 PDT
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) 2012-04-06 05:53:58 PDT
(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) 2012-04-06 07:46:44 PDT
(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 2012-04-06 10:45:42 PDT
Decoder, it would be nice if you tried to remove/shorten the iloops before posting. It makes bisecting and verifying easier :)
Comment 17 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-05-31 15:59:03 PDT
Verified fixed in Firefox 10 and ESR:10.
Comment 18 Christian Holler (:decoder) 2013-03-11 09:04:31 PDT
Even without iloop, this test takes very long to complete, not taking into the testsuite.

Note You need to log in before you can comment on or make changes to this bug.