+++ This bug was initially created as a clone of Bug #810560 +++ https://tbpl.mozilla.org/php/getParsedLog.php?id=17008727&tree=Mozilla-Inbound Rev3 WINNT 5.1 mozilla-inbound debug test mochitest-1 on 2012-11-13 17:37:04 PST for push b04cea4ab159 slave: talos-r3-xp-093 28389 INFO TEST-START | /tests/content/base/test/test_bug428847.html ++DOMWINDOW == 79 (0720AE20) [serial = 474] [outer = 0B5C0B98] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004003: file e:/builds/moz2_slave/m-in-w32-dbg/build/intl/uconv/src/nsCharsetConverterManager.cpp, line 301 ++DOCSHELL 0C129D08 == 31 [id = 118] ++DOMWINDOW == 80 (0705FCC8) [serial = 475] [outer = 00000000] WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv) && subjPrincipal) failed: file e:/builds/moz2_slave/m-in-w32-dbg/build/docshell/base/nsDocShell.cpp, line 8194 ++DOMWINDOW == 81 (0B75DB98) [serial = 476] [outer = 0705FC78] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040111: file e:/builds/moz2_slave/m-in-w32-dbg/build/content/base/src/nsCrossSiteListenerProxy.cpp, line 487 ++DOMWINDOW == 82 (0BF5CC38) [serial = 477] [outer = 0705FC78] Assertion failure: !thing->compartment()->scheduledForDestruction, at e:/builds/moz2_slave/m-in-w32-dbg/build/js/src/gc/Marking.cpp:92 nsStringStats => mAllocCount: 423120 => mReallocCount: 36838 => mFreeCount: 402786 -- LEAKED 20334 !!! => mShareCount: 742324 => mAdoptCount: 35443 => mAdoptFreeCount: 35440 -- LEAKED 3 !!! TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_bug428847.html | Exited with code -2147483645 during test run INFO | automation.py | Application ran for: 0:06:49.125000 INFO | automation.py | Reading PID log: c:\docume~1\cltbld\locals~1\temp\tmp0aqenvpidlog ==> process 3368 launched child process 3244 INFO | automation.py | Checking for orphan process with PID: 3244 Downloading symbols from: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32-debug/1352852089/firefox-19.0a1.en-US.win32.crashreporter-symbols.zip PROCESS-CRASH | /tests/content/base/test/test_bug428847.html | application crashed (minidump found) Crash dump filename: c:\docume~1\cltbld\locals~1\temp\tmp6thhpz\minidumps\3114578f-30ee-437f-b6db-641a86230d81.dmp Operating system: Windows NT 5.1.2600 Service Pack 2 CPU: x86 GenuineIntel family 6 model 23 stepping 10 2 CPUs Crash reason: EXCEPTION_BREAKPOINT Crash address: 0xd94e9d Thread 0 (crashed) 0 mozjs.dll!js::gc::CheckMarkedThing<JSObject> [Marking.cpp:b04cea4ab159 : 92 + 0x53] eip = 0x00d94e9d esp = 0x0012c9b0 ebp = 0x0012c9c0 ebx = 0x7c80e00d esi = 0x10261440 edi = 0x7c801e16 eax = 0x00000000 ecx = 0xb7c9469d edx = 0x10361f48 efl = 0x00000212 Found by: given as instruction pointer in context 1 mozjs.dll!js::gc::MarkInternal<JSObject>(JSTracer *,JSObject * *) [Marking.cpp:b04cea4ab159 : 113 + 0x9] eip = 0x00d9b305 esp = 0x0012c9c8 ebp = 0x0012c9dc Found by: call frame info 2 mozjs.dll!js::gc::MarkObjectUnbarriered(JSTracer *,JSObject * *,char const *) [Marking.cpp:b04cea4ab159 : 244 + 0x23] eip = 0x00d9f134 esp = 0x0012c9e4 ebp = 0x0012c9ec Found by: call frame info 3 mozjs.dll!js::ObjectImpl::writeBarrierPre(js::ObjectImpl *) [ObjectImpl-inl.h:b04cea4ab159 : 438 + 0x18] eip = 0x00a289fe esp = 0x0012c9f4 ebp = 0x0012ca14 Found by: call frame info 4 mozjs.dll!js::IncrementalReferenceBarrier(void *) [jsfriendapi.cpp:b04cea4ab159 : 912 + 0x5] eip = 0x00acc7ec esp = 0x0012ca1c ebp = 0x0012ca2c Found by: call frame info 5 xul.dll!xpc_UnmarkGrayObject(JSObject *) [xpcpublic.h:b04cea4ab159 : 152 + 0x6] eip = 0x01f8fed2 esp = 0x0012ca34 ebp = 0x0012ca3c Found by: call frame info 6 xul.dll!XPCConvert::NativeInterface2JSObject(XPCLazyCallContext &,JS::Value *,nsIXPConnectJSObjectHolder * *,xpcObjectHelper &,nsID const *,XPCNativeInterface * *,bool,tag_nsresult *) [XPCConvert.cpp:b04cea4ab159 : 830 + 0xb] eip = 0x02799e38 esp = 0x0012ca44 ebp = 0x0012ca88 Found by: call frame info 7 xul.dll!xpc_qsXPCOMObjectToJsval(XPCLazyCallContext &,qsObjectHelper &,nsID const *,XPCNativeInterface * *,JS::Value *) [XPCQuickStubs.cpp:b04cea4ab159 : 995 + 0x1f] eip = 0x027d23ea esp = 0x0012ca90 ebp = 0x0012cac0 Found by: call frame info 8 xul.dll!nsIDOMEvent_GetTarget [dom_quickstubs.cpp:b04cea4ab159 : 4709 + 0x1d] eip = 0x028194e1 esp = 0x0012cac8 ebp = 0x0012cba4
Crash Signature: [@ js::gc::CheckMarkedThing<JSObject>]
Summary: Intermittent Assertion failure: !thing->compartment()->scheduledForDestruction in test_bug428847.html [@ js::gc::CheckMarkedThing<JSObject>] → Intermittent Assertion failure: !thing->compartment()->scheduledForDestruction in test_bug428847.html, test_bug583948.xul [@ js::gc::CheckMarkedThing<JSObject>]
Created attachment 692673 [details] [diff] [review] patch Olli found a way to reproduce this, and with bz's help I think I figured out what's causing it. Let's say that there's a window that gets destroyed, but somebody still has a reference to one of its DOM nodes. The window's compartment has been nuked and there's no reason to keep any of the JS objects alive, since the live DOM node holds its JS reflector weakly. Then we start doing an incremental GC. At the beginning, it looks like we can destroy the window's compartment. However, during the incremental GC, some JS code in another compartment walks over to the live DOM node via whatever had been keeping it alive. Now we need the JS reflector for the DOM node. The DOM node's wrapper cache entry still points to the supposedly dead compartment, so we pull out that wrapper. This causes an UnmarkGray operation, which resurrects the dead compartment. In theory we could have an elaborate mechanism for detecting this and ensuring that the compartment does indeed get destroyed. However, this happens so rarely that I don't think it's worth it. Instead, I changed the assertion to fire only during a brain transplant. This still accomplishes the main goal of the assertion--that we don't regress all of the funky brain transplant code that avoids leaks. It doesn't give us the stronger property that we were interested in about whether dead compartments are ever resurrected by incremental GC. However, at least we have an understanding now of when that might happen and how likely it is.
Assignee: general → wmccloskey
Status: NEW → ASSIGNED
Attachment #692673 - Flags: review?(luke)
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Probably should stay open for a bit to confirm it is really fixed in the wild.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [leave open]
For TBPL intermittent-failure bugs, we typical close as fixed and reopen if a branch that has the fix is starred into the bug. With the [leave open] in the whiteboard, we'll actually never close this, since my "look for intermittent failure bugs that haven't occurred for 3 months" saved search explicitly ignores bugs with [leave open]. Happy for you to mark however you feel most appropriate however, given that the most important thing it that this is (hopefully) now fixed :-D
Based on the stacks, I would be very surprised if this recurs. If it does, we can always reopen.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago → 5 years ago
Resolution: --- → FIXED
Whiteboard: [leave open]
Oops, thanks for the explanation Ed!
You need to log in before you can comment on or make changes to this bug.