660517 - "ASSERTION: unable to transplant wrappers, probably OOM"

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jesse Ruderman]

Attachment: testcase

###!!! ASSERTION: unable to transplant wrappers, probably OOM: 'Error', file dom/base/nsGlobalWindow.cpp, line 2096

(It's not OOM.)

And there are also several errors from chrome code in tabbrowser.xml and nsLoginManager.js, which is worrisome:

JavaScript error: , line 0: uncaught exception: [Exception... "Could not convert Native argument arg 0 [nsIWebProgress.DOMWindow]"  nsresult: "0x8057000a (NS_ERROR_XPC_BAD_CONVERT_NATIVE)"  location: "JS frame :: chrome://browser/content/tabbrowser.xml :: <TOP_LEVEL> :: line 605"  data: no]

[Exception... "Could not convert Native argument arg 0 [nsIWebProgress.DOMWindow]"  nsresult: "0x8057000a (NS_ERROR_XPC_BAD_CONVERT_NATIVE)"  location: "JS frame :: resource:///components/nsLoginManager.js :: <TOP_LEVEL> :: line 285"  data: no]

JavaScript error: , line 0: uncaught exception: [Exception... "Could not convert Native argument arg 0 [nsIWebProgress.DOMWindow]"  nsresult: "0x8057000a (NS_ERROR_XPC_BAD_CONVERT_NATIVE)"  location: "JS frame :: chrome://browser/content/tabbrowser.xml :: <TOP_LEVEL> :: line 547"  data: no]

Comment 1

[Jesse Ruderman]

Attachment: stack trace for the assertion

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to comment #0)
> (It's not OOM.)

No, it's the next best thing: E4X!

The exception and assertion stem from the fact that we refuse to wrap E4X objects in proxies. When we navigate back, we need to transplant the old outer window into a proxy, including its prototype. But that fails in this case.

Is there any way that we can detect someone setting a wrapped native's prototype to an E4X object and throw then?

Leaving this as security sensitive, though I'm not sure exactly what the consequences of a brain transplant failing are. My not-so-extensive experience says "zombies".

Comment 3

[Daniel Veditz [:dveditz]]

If we've got the wrong brain there's no telling what we could do, sg:high cross-origin stuff or maybe even sg:critical if there's chrome cross-compartment leakage.

Comment 4

[Johnny Stenback (:jst)]

Is there ever a reason to have an E4X object on a prototype chain?

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

No.

Comment 6

[Jeff Walden [:Waldo]]

Attachment: Does what it says on the box, haven't tested original yet but expect goodness

Comment 8

[Johnny Stenback (:jst)]

Can we get this landed?

Comment 9

[Jeff Walden [:Waldo]]

http://hg.mozilla.org/tracemonkey/rev/a4d39f157859

Landed in TM 3.5h before comment 8.  :-)

Comment 10

[Chris Leary [:cdleary] (not checking bugmail)]

cdleary-bot mozilla-central merge info:
http://hg.mozilla.org/mozilla-central/rev/a4d39f157859

Comment 11

[Johnny Stenback (:jst)]

This patch is good for 6, right? If so, please request beta approval for the patch!

Comment 12

[Jeff Walden [:Waldo]]

Comment on attachment 539915 [details] [diff] [review]
Does what it says on the box, haven't tested original yet but expect goodness

Yeah, this should be good for aurora/beta/&c.

Comment 13

[Asa Dotzler [:asa]]

We'll get to this approval requests on Monday's 2pm PT triage.

Comment 14

[Jeff Walden [:Waldo]]

http://hg.mozilla.org/releases/mozilla-beta/rev/fda101def1ec

I guess the m-a a? wasn't necessary, because this landed before the last train departure, so it was already in mozilla-aurora and only had to land in mozilla-beta.  No biggie, I guess.  :-)

Comment 15

[Daniel Veditz [:dveditz]]

Appears to be a regression, does not happen on the 1.9.2 branch (worst case: the assertion doesn't exist but the problem does).

Comment 16

[u279076]

qa+ for verification in Firefox 7 using the attached testcase

Comment 17

[u279076]

Changing to qa- as this is an assertion.