383552 - Frequent crash [@ ToParticipant] after closing a tab

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Jesse Ruderman]

This happened to me twice just now, both times shortly after I closed a tab (Mac trunk debug).  I suspect that this is a regression from bug 383234.

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000040

Thread 0 Crashed:
0   <<00000000>> 	0x00000040 0 + 64
1   libxpcom_core.dylib      	0x0136776a ToParticipant(nsISupports*, nsXPCOMCycleCollectionParticipant**) + 30 (nsCycleCollector.cpp:929)
2   libxpcom_core.dylib      	0x01367f31 nsCycleCollector::MarkRoots(GCGraph&) + 109 (nsCycleCollector.cpp:1208)
3   libxpcom_core.dylib      	0x01368a98 nsCycleCollector::Collect(unsigned) + 346 (nsCycleCollector.cpp:2000)
4   libxpcom_core.dylib      	0x01368b80 nsCycleCollector_collect() + 48 (nsCycleCollector.cpp:2256)
5   libgklayout.dylib        	0x17f9947d nsJSContext::Notify(nsITimer*) + 165 (nsJSEnvironment.cpp:3193)
6   libxpcom_core.dylib      	0x0135c57d nsTimerImpl::Fire() + 925 (nsTimerImpl.cpp:387)
7   libxpcom_core.dylib      	0x0135c709 nsTimerEvent::Run() + 191 (nsTimerImpl.cpp:458)
8   libxpcom_core.dylib      	0x01358bb4 nsThread::ProcessNextEvent(int, int*) + 508 (nsThread.cpp:483)
9   libxpcom_core.dylib      	0x0130453e NS_ProcessNextEvent_P(nsIThread*, int) + 76 (nsThreadUtils.cpp:227)
10  libwidget_mac.dylib      	0x0550c274 nsBaseAppShell::Run() + 70 (nsBaseAppShell.cpp:153)
11  libwidget_mac.dylib      	0x054f0398 nsAppShell::Run() + 190 (nsAppShell.mm:348)
12  libwidget_mac.dylib      	0x054f067a -[AppShellDelegate runAppShell] + 36 (nsAppShell.mm:447)
13  com.apple.Foundation     	0x9280503b __NSFireDelayedPerform + 403
14  com.apple.CoreFoundation 	0x9082c7e2 CFRunLoopRunSpecific + 3341
15  com.apple.CoreFoundation 	0x9082bace CFRunLoopRunInMode + 61
16  com.apple.HIToolbox      	0x92de78d8 RunCurrentEventLoopInMode + 285
17  com.apple.HIToolbox      	0x92de6fe2 ReceiveNextEventCommon + 385
18  com.apple.HIToolbox      	0x92de6e39 BlockUntilNextEventMatchingListInMode + 81
19  com.apple.AppKit         	0x9328d465 _DPSNextEvent + 572
20  com.apple.AppKit         	0x9328d056 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 137
21  libwidget_mac.dylib      	0x054f018f nsAppShell::ProcessNextNativeEvent(int) + 275 (nsAppShell.mm:302)
22  libwidget_mac.dylib      	0x0550c21b nsBaseAppShell::DoProcessNextNativeEvent(int) + 51 (nsBaseAppShell.cpp:137)
23  libwidget_mac.dylib      	0x0550c5e0 nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, int, unsigned) + 94 (nsBaseAppShell.cpp:225)
24  libwidget_mac.dylib      	0x054f045a nsAppShell::OnProcessNextEvent(nsIThreadInternal*, int, unsigned) + 180 (nsAppShell.mm:372)
25  libxpcom_core.dylib      	0x01358ab0 nsThread::ProcessNextEvent(int, int*) + 248 (nsThread.cpp:472)
26  libxpcom_core.dylib      	0x0130462b NS_ProcessPendingEvents_P(nsIThread*, unsigned) + 91 (nsThreadUtils.cpp:180)
27  libwidget_mac.dylib      	0x0550c1b7 nsBaseAppShell::NativeEventCallback() + 83 (nsBaseAppShell.cpp:116)
28  libwidget_mac.dylib      	0x054f0c17 nsAppShell::ProcessGeckoEvents() + 263 (nsAppShell.mm:213)
29  libwidget_mac.dylib      	0x054f0d61 -[AppShellDelegate handlePortMessage:] + 107 (nsAppShell.mm:438)
30  com.apple.Foundation     	0x928409c0 __NSFireMachPort + 307
31  com.apple.CoreFoundation 	0x9083c385 __CFMachPortPerform + 136
32  com.apple.CoreFoundation 	0x9082c62d CFRunLoopRunSpecific + 2904
33  com.apple.CoreFoundation 	0x9082bace CFRunLoopRunInMode + 61
34  com.apple.HIToolbox      	0x92de78d8 RunCurrentEventLoopInMode + 285
35  com.apple.HIToolbox      	0x92de6f19 ReceiveNextEventCommon + 184
36  com.apple.HIToolbox      	0x92de6e39 BlockUntilNextEventMatchingListInMode + 81
37  com.apple.AppKit         	0x9328d465 _DPSNextEvent + 572
38  com.apple.AppKit         	0x9328d056 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 137
39  com.apple.AppKit         	0x93286ddb -[NSApplication run] + 512
40  libwidget_mac.dylib      	0x054f036c nsAppShell::Run() + 146 (nsAppShell.mm:345)
41  libtoolkitcomps.dylib    	0x16ab2edb nsAppStartup::Run() + 147 (nsAppStartup.cpp:171)
42  XUL                      	0x0020f3a1 XRE_main + 9817 (nsAppRunner.cpp:2814)
43  org.mozilla.firefox      	0x00002ec0 main + 40 (nsBrowserApp.cpp:70)
44  org.mozilla.firefox      	0x00002826 _start + 216
45  org.mozilla.firefox      	0x0000274d start + 41

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Hrm.  This code looks like it assumes that all roots are XPCOM cycle collection participants, never other types.  That seems wrong, especially with the patch to suspect all native wrappers.  (But we should probably also make the nsRefPtr-based XBL objects put themselves in the purple buffer as well.)

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(That said, that assumption wouldn't explain the crash.)

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Actually, it's fine for native wrappers, but it's probably not the best assumption for future work.

Maybe regression from bug 368869?

Comment 4

[Peter Van der Beken [:peterv]]

(In reply to comment #1)
> Hrm.  This code looks like it assumes that all roots are XPCOM cycle collection
> participants, never other types.  That seems wrong, especially with the patch
> to suspect all native wrappers.

Currently only XPCOM objects suspect themselves. If we want to have non-XPCOM objects suspect themselves we'll probably need to store the participant along with the pointer in the purple buffer.

Comment 5

[Jesse Ruderman]

WFM now that bug 368869 has been backed out.

Comment 6

[Jesse Ruderman]

I'm seeing these crashes again.

Comment 7

[Benjamin Smedberg]

I only find one breakpad report with this signature:

http://crash-stats.mozilla.com/report/list?range_unit=months&range_value=1&signature=nsCycleCollectionXPCOMRuntime%3A%3AToParticipant(void+*)

So blocking- unless it shows up there.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This was fixed by the newer version of bug 368869.