Closed Bug 811587 Opened 12 years ago Closed 12 years ago

Intermittent Assertion failure: !thing->compartment()->scheduledForDestruction in test_bug428847.html, test_bug583948.xul [@ js::gc::CheckMarkedThing<JSObject>]

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla20
Tracking Flags:
Tracking Status
firefox18 --- unaffected
firefox19 --- affected

People

(Reporter: philor, Assigned: billm)

References

Details

(Keywords: assertion, intermittent-failure)

Crash Data

Attachments

(1 file)

patch
2.44 KB, patch
luke
: review+
Details | Diff | Splinter Review 
+++ 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>]
https://tbpl.mozilla.org/php/getParsedLog.php?id=17145015&tree=Firefox
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>]
Whiteboard: [orange]
Attached patch patch — — Splinter Review 
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)
Attachment #692673 - Flags: review?(luke) → review+
https://hg.mozilla.org/mozilla-central/rev/6457767f5277
Status: ASSIGNED → RESOLVED
Closed: 12 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
Closed: 12 years ago → 12 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.

Attachment

General

Creator:
Created:
Updated:
Size: