Closed
Bug 770713
Opened 12 years ago
Closed 12 years ago
Assertion failure: [infer failure] Missing type pushed 0: <0xf6c03040>, at jsinfer.cpp:325
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla17
People
(Reporter: decoder, Assigned: billm)
Details
(Keywords: assertion, testcase)
Attachments
(1 file)
919 bytes,
patch
|
bhackett1024
:
review+
|
Details | Diff | Splinter Review |
The following test asserts on mozilla-central revision b39f4007be5a (options -m -n -a): gczeal(4); var a = ['a','test string',456,9.34,new String("string object"),[],['h','i','j','k']]; var b = [1,2,3,4,5,6,7,8,9,0]; exhaustiveSliceTest("exhaustive slice test 1", a); function mySlice(a, from, to) { var returnArray = []; try { } catch ( [ x ] ) { } finally { } return returnArray; } function exhaustiveSliceTest(testname, a) { var x = 0; for (y = (2 + a.length); y >= -(2 + a.length); y--) { var c = mySlice(a,x,y); if (String(b) != String(c)) " expected result: " + String(c) + "\n"; } } S-s because infer failures can be security-critical.
Comment 1•12 years ago
|
||
The first "bad" revision is: changeset: f2a937c4fb99 user: Jon Coppeard <jcoppeard@mozilla.com> date: Fri Jun 22 11:25:21 2012 +0100 summary: Bug 763984: Add new zeal modes to test incremental GC r=billm
Comment 2•12 years ago
|
||
taking off "js-triage-needed" in case that's interfering with the new js triage process
Whiteboard: js-triage-needed
Comment 3•12 years ago
|
||
(In reply to Jesse Ruderman from comment #1) I can reproduce this (using the script below) back to: changeset: 8d857c53bc0a user: Bill McCloskey <wmccloskey@mozilla.com> date: Tue Jun 12 12:24:31 2012 -0700 summary: Bug 753283 - Poison VM stack to help fuzzers (r=bhackett) I guess this means that this is an existing problem that has been highlighted by this change. gczeal(4); var a = ['a','test string',456,9.34,new String("string object"),[],['h','i','j','k']]; var b = [1,2,3,4,5,6,7,8,9,0]; function mySlice(a, from, to) { var returnArray = []; try { } catch ( [ x ] ) { } finally { } return returnArray; } function exhaustiveSliceTest(testname, a) { var x = 0; for (y = (2 + a.length); y >= -(2 + a.length); y--) { var c = mySlice(a,x,y); if (String(b) != String(c)) " expected result: " + String(c) + "\n"; } } exhaustiveSliceTest("exhaustive slice test 1", a); exhaustiveSliceTest("exhaustive slice test 1", a); exhaustiveSliceTest("exhaustive slice test 1", a); exhaustiveSliceTest("exhaustive slice test 1", a);
Assignee | ||
Updated•12 years ago
|
Assignee: general → wmccloskey
Assignee | ||
Comment 4•12 years ago
|
||
Here's what's happening. At the end of a RETSUB bytecode, we call the write barrier verifier (as we do at the end of every bytecode). However, RETSUB has a funny way of incrementing the PC. It causes the stack scanning part of the barrier verifier to think that we're at the start of the function, which leads to incorrect information about what vars are live, and we end up overwriting a live variable as if it were dead. The fix is to use a slightly less weird way of updating the PC in JSOP_RETSUB. I didn't see any other ops that work this way.
Attachment #649853 -
Flags: review?(bhackett1024)
Updated•12 years ago
|
Attachment #649853 -
Flags: review?(bhackett1024) → review+
Assignee | ||
Comment 6•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/b90a734c9336
Comment 7•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/b90a734c9336
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Reporter | ||
Comment 8•11 years ago
|
||
Automatically extracted testcase for this bug was committed: https://hg.mozilla.org/mozilla-central/rev/efaf8960a929
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•