Closed
Bug 607015
Opened 15 years ago
Closed 8 years ago
OS X crash report dialog comes up for plugin-container when Firefox crashes
Categories
(Core :: IPC, defect)
Tracking
()
RESOLVED
WORKSFORME
| Tracking | Status | |
|---|---|---|
| blocking2.0 | --- | - |
People
(Reporter: bent.mozilla, Unassigned)
Details
Recent nightlies have been very crashy for me on OS X (bug 604734) and I'm seeing the OS X crash report dialog for the plugin process almost every time. Breakpad catches the firefox crash and submits the reports just like always, but the plugin process seems to be unable to handle it.
| Reporter | ||
Updated•15 years ago
|
blocking2.0: --- → ?
I've seen something similar on Windows when firefox dies and plugin-container gets the standard Windows crash dialog.
Comment 2•15 years ago
|
||
The plugin process aborts when it detects that its parent has died... which is good. The real bug here is just that we should suppress the OS X dialog? I don't think that's a blocker. We have the same issue on Windows.
blocking2.0: ? → -
| Reporter | ||
Comment 3•15 years ago
|
||
I don't think the plugin is aborting. Here's the snippet from the crash report:
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 XUL 0x00defb49 mozilla::plugins::PPluginInstanceChild::SendNPN_InvalidateRect(_NPRect const&) + 297
<no further stack>
blocking2.0: - → ?
Comment 4•15 years ago
|
||
cjones, are we not aborting the plugin process?
bent, I'd love if you attached to plugin-container in a debugger and got a better stack. I can't, as I don't have an OOPP-enabled mac.
We exit gently: http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginModuleChild.cpp#570, discussion in bug 540097. Whatever is happening in comment 3 might be before or after ActorDestroy() notification. If it's before, then abort-on-parent-exit wouldn't help.
| Reporter | ||
Comment 6•15 years ago
|
||
This is an opt nightly, so I don't know how reliable this is, but I finally caught this:
Thread 4 (process 14380):
#0 0x97e54942 in kevent ()
#1 0x00eb5490 in kq_dispatch ()
Previous frame inner to this frame (gdb could not unwind past this frame)
Thread 3 (process 14380):
#0 0x97e2e0fa in mach_msg_trap ()
#1 0x97e2e867 in mach_msg ()
#2 0x00036c1b in google_breakpad::ExceptionHandler::WaitForMessage ()
#3 0x97e5b6a2 in thread_start ()
Thread 1 (process 14380): *crashed*
#0 0x00defb49 in mozilla::plugins::PPluginInstanceChild::SendNPN_InvalidateRect ()
#1 0x00d7666c in mozilla::plugins::PluginInstanceChild::InvalidateRect ()
#2 0x1699182e in unregister_ShockwaveFlash ()
#3 0x16995021 in unregister_ShockwaveFlash ()
#4 0x1687db77 in gAVAHDMainPluginHead ()
#5 0x168b546f in gAVAHDMainPluginHead ()
#6 0x16a0dc57 in main ()
#7 0x95265f91 in __CFRunLoopDoSources0 ()
#8 0x95263bbf in __CFRunLoopRun ()
#9 0x95263094 in CFRunLoopRunSpecific ()
#10 0x95262ec1 in CFRunLoopRunInMode ()
#11 0x940a4f9c in RunCurrentEventLoopInMode ()
#12 0x940a4d51 in ReceiveNextEventCommon ()
#13 0x940a4bd6 in BlockUntilNextEventMatchingListInMode ()
#14 0x9292fa89 in _DPSNextEvent ()
#15 0x9292f2ca in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#16 0x928f155b in -[NSApplication run] ()
#17 0x00ece329 in base::MessagePumpNSApplication::DoRun ()
Updated•15 years ago
|
blocking2.0: ? → -
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•