Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060113 Firefox/1.6a1 To reproduce, load http://www.live.com/, then exit Firefox. Leaked outer window 35d8980 at address 35d8980. Leaked inner window 4a5b040 (outer 35d8980) at address 4a5b040. ... with URI "http://www.live.com/". Leaked document at address c879e00. ... with URI "http://www.live.com/". Leaked document at address 4a94c20. ... with URI "chrome://global/content/bindings/scrollbar.xml". Leaked document at address 4a921d0. ... with URI "chrome://global/content/bindings/nativescrollbar.xml". Leaked document at address 519bb20. ... with URI "http://www.live.com/gadgets/weather/weather.xml". Leaked document at address 51419c0. ... with URI "chrome://global/content/platformHTMLBindings.xml".
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060114 Firefox/1.6a1 ID:2006011405 I see this too --> all/all
OS: MacOS X → All
Hardware: Macintosh → All
*** Bug 339556 has been marked as a duplicate of this bug. ***
Still happens in a 2006-05-29 trunk nightly.
Created attachment 223801 [details] simplified testcase This leak is caused by the following cycle: 1) nsJSContext has an nsCOMPtr member variable that keeps the XPCWrappedNative for the global object alive and rooted 2) the global object keeps an XMLHttpRequest object alive via the JS GC; in the real thing the GC trace is the following: 09ce6028 object 0xa100938 XMLHttpRequest via global object(Window @ 0x09c9e668).XPCWrappedNativeProto::mJSProtoObject(XPC_WN_ModsAllowed_Proto_JSClass @ 0x09c9ce28).innerHeight getter(Function @ 0x0a0876c0).__proto__(Function @ 0x09c9e578).constructor(Function @ 0x09c9e570).KillEvent(Function @ 0x0a087680).__parent__(Call @ 0x0a087688).__proto__(Call @ 0x09fa0040).arguments(Object @ 0x0a189868).1(Object @ 0x0a189ae0).parent(Object @ 0x09a26d20).initialize(Function @ 0x0a041200).__parent__(Call @ 0x09a26d10).e(Object @ 0x09ce6f88).xml(XMLHttpRequest @ 0x09ce6028). but in the testcase it's much simpler. 3) the nsXMLHttpRequest keeps the nsJSContext alive via its mScriptContext member variable, set via any of the event handler setters or other things. Note that I'm seeing the bizarre behavior that once I've run this testcase, I leak even when I don't load it anymore. I need to look into that.
Note that I think we probably ought to be breaking both (1) and (3).
Except a fix for (1) that fixes the extra rooted XPCWrappedNative doesn't actually fix the cycle.
Never mind comment 6; I just wasn't breaking enough. It's both the XPCWrappedNative and the fact that it's the global object. Although I'd have thought that JS_ClearScope would have been sufficient, but it wasn't...
Jonas - is this something you can take a look at?
I'll give it a shot.
Assignee: general → bugmail
dbaron says dup of bug he just fixed *** This bug has been marked as a duplicate of 353090 ***
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
Worth retesting, though. Jesse, could you have a look?
I don't see any DOMWindow leaks with the testcase here or with live.com, using a fresh Mac trunk debug build. (The appearance of live.com has changed completely since I reported this bug...)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.