Closed Bug 774953 Opened 8 years ago Closed 8 years ago

"Assertion failure: [infer failure] Missing type pushed 0" with iframes, adoptNode

Categories

(Core :: JavaScript Engine, defect, critical)

x86_64
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla17
Tracking Status
firefox16 --- affected
firefox17 --- verified
firefox-esr10 --- unaffected

People

(Reporter: jruderman, Assigned: bhackett1024)

References

Details

(Keywords: assertion, sec-critical, testcase, Whiteboard: [js:p1:fx17][adv-track-main17+])

Attachments

(3 files)

Attached file testcase
With
  user_pref("javascript.options.methodjit_always", true);
the testcase triggers:

Assertion failure: [infer failure] Missing type pushed 0: [0x10a0398e0], at js/src/jsinfer.cpp:325

Based on js/xpconnect/crashtests/515726-1.html
Attached file TI spew & stack trace
Whiteboard: [js:p1]
Whiteboard: [js:p1] → [js:p1:fx17]
Duplicate of this bug: 779020
I'm in the process of bisecting this. It is a bug on mozilla-central but is only causing problems on the IonMonkey TBPL for some reason.
Assignee: general → dvander
Status: NEW → ASSIGNED
The problem has something to do with the proto->setNewTypeUnknown() call that was removed from JS_NewObject(). The problem seems to be that if the objects are swap()ed, then the type information will be inaccurate.
Attached patch patchSplinter Review
This passes the testcases in this bug and bug 779020 (got the crash without the patch in bug 779020, didn't test with this one).  The problem is that JSObject::swap swaps the two types of the objects, which will break the correctness of type sets which either object appeared in if the objects have not had all sets they appear in marked as unknown.  This fix keeps the type of an object stable across swaps, though it will get SetProto'ed to get the prototype of the other object which will mark its sets as unknown anyways.
Assignee: dvander → bhackett1024
Attachment #651062 - Flags: review?(dvander)
Comment on attachment 651062 [details] [diff] [review]
patch

Thanks!
Attachment #651062 - Flags: review?(dvander) → review+
Backed out in http://hg.mozilla.org/integration/mozilla-inbound/rev/b753e1dce89f - mochitest-chrome, "dom/tests/mochitest/whatwg/test_postMessage_chrome.html | Test timed out," so far looking like every OS and opt+debug.
ReserveForTradeGuts had a premature return that skipped the prototype swapping.

https://hg.mozilla.org/integration/mozilla-inbound/rev/d29b79c37f86
https://hg.mozilla.org/mozilla-central/rev/d29b79c37f86
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Marking as unaffected since bug 766447, the regressing bug, landed in FF16.
Keywords: verifyme
Verified.

Confirmed testcase crashes 2012-7-17 Firefox 17.0a1 Nightly Debug
Confirmed testcase crashes 2012-9-29 Firefox 16.0 Nightly Debug
Does not crash 2012-10-17 Firefox 17.0b2
Status: RESOLVED → VERIFIED
Whiteboard: [js:p1:fx17] → [js:p1:fx17][adv-track-main17+]
Group: core-security
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.