Closed Bug 383552 Opened 17 years ago Closed 17 years ago

Frequent crash [@ ToParticipant] after closing a tab

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jruderman, Assigned: dbaron)

References

Details

(Keywords: crash, dogfood, regression)

Crash Data

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
Flags: blocking1.9?
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.)
(That said, that assumption wouldn't explain the crash.)
Actually, it's fine for native wrappers, but it's probably not the best assumption for future work. Maybe regression from bug 368869?
(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.
WFM now that bug 368869 has been backed out.
Blocks: 368869
No longer blocks: 383234
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
I'm seeing these crashes again.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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.
Flags: blocking1.9? → blocking1.9-
Assignee: nobody → dbaron
Status: REOPENED → NEW
This was fixed by the newer version of bug 368869.
Status: NEW → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Crash Signature: [@ ToParticipant]
You need to log in before you can comment on or make changes to this bug.