Closed Bug 693451 Opened 13 years ago Closed 12 years ago

[10.7] Empty plugin side crash reports


(Toolkit :: Crash Reporting, defect)

Not set





(Reporter: marcia, Assigned: ted)


(Blocks 1 open bug)


Crash Data

Seen while looking at chofmann's Mac report. This hang consistently shows in the top 5 10.7 specific issues in chofmann's report.|%20__psynch_mutexwait

Frame 	Module 	Signature [Expand] 	Source
0 	libsystem_kernel.dylib 	__psynch_mutexwait 	
1 	libsystem_c.dylib 	pthread_mutex_lock 	
2 	XUL 	google_breakpad::ExceptionHandler::WriteMinidump 	toolkit/crashreporter/google-breakpad/src/client/mac/handler/
3 	XUL 	CrashReporter::CreatePairedMinidumps 	toolkit/crashreporter/nsExceptionHandler.cpp:2098
4 	XUL 	mozilla::plugins::PluginModuleParent::ShouldContinueFromReplyTimeout 	dom/plugins/ipc/PluginModuleParent.cpp:259
5 	XUL 	mozilla::plugins::PPluginModuleParent::OnReplyTimeout 	obj-firefox/x86_64/ipc/ipdl/PPluginModuleParent.cpp:1125
6 	XUL 	mozilla::ipc::SyncChannel::ShouldContinueFromTimeout 	ipc/glue/SyncChannel.cpp:264
7 	XUL 	mozilla::ipc::RPCChannel::Call 	ipc/glue/RPCChannel.cpp:210
8 	XUL 	mozilla::plugins::PPluginInstanceParent::CallNPP_HandleEvent 	obj-firefox/x86_64/ipc/ipdl/PPluginInstanceParent.cpp:496
9 	XUL 	mozilla::plugins::PluginInstanceParent::NPP_HandleEvent 	dom/plugins/ipc/PluginInstanceParent.cpp:1270
10 	XUL 	mozilla::plugins::PluginModuleParent::NPP_HandleEvent 	dom/plugins/ipc/PluginModuleParent.cpp:546
11 	XUL 	nsNPAPIPluginInstance::HandleEvent 	dom/plugins/base/nsNPAPIPluginInstance.cpp:576
12 	XUL 	nsPluginInstanceOwner::ProcessEvent 	dom/plugins/base/nsPluginInstanceOwner.cpp:2060
13 	XUL 	nsPluginInstanceOwner::DispatchMouseToPlugin 	dom/plugins/base/nsPluginInstanceOwner.cpp:1819
14 	XUL 	nsPluginInstanceOwner::HandleEvent 	dom/plugins/base/nsPluginInstanceOwner.cpp:1864
15 	XUL 	nsEventListenerManager::HandleEventSubType 	content/events/src/nsEventListenerManager.cpp:865
16 	XUL 	nsEventListenerManager::HandleEventInternal 	content/events/src/nsEventListenerManager.cpp:919
17 	XUL 	nsEventTargetChainItem::HandleEventTargetChain 	content/events/src/nsEventListenerManager.h:147
18 	XUL 	nsEventDispatcher::Dispatch 	content/events/src/nsEventDispatcher.cpp:672
19 	XUL 	PresShell::HandleEventInternal 	layout/base/nsPresShell.cpp:7087
20 	XUL 	PresShell::HandlePositionedEvent 	layout/base/nsPresShell.cpp:6920
21 	XUL 	PresShell::HandleEvent 	layout/base/nsPresShell.cpp:6755
22 	XUL 	PresShell::HandleEvent 	layout/base/nsPresShell.cpp:6510
23 	XUL 	nsViewManager::DispatchEvent 	view/src/nsViewManager.cpp:1029
24 	XUL 	HandleEvent 	view/src/nsView.cpp:159
25 	XUL 	nsChildView::DispatchEvent 	widget/src/cocoa/
26 	XUL 	nsChildView::DispatchWindowEvent 	widget/src/cocoa/
27 	XUL 	-[ChildView mouseUp:] 	widget/src/cocoa/
28 	AppKit 	-[NSWindow sendEvent:] 	
29 	XUL 	-[ToolbarWindow sendEvent:] 	widget/src/cocoa/
30 	AppKit 	-[NSApplication sendEvent:] 	
31 	XUL 	-[GeckoNSApplication sendEvent:] 	widget/src/cocoa/
32 	AppKit 	-[NSApplication run] 	
33 	XUL 	nsAppShell::Run 	widget/src/cocoa/
34 	XUL 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:224
35 	XUL 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3544
36 	firefox 	main 	browser/app/nsBrowserApp.cpp:198
37 	firefox 	firefox@0xac3
Add on correlations from 7.0, but don't really show enough volume:

7% (2/27) vs.   0% (7/1858) (Alexa Sparky,
      7% (2/27) vs.   1% (15/1858) ( Toolbar - Tube Downloader,
      7% (2/27) vs.   1% (19/1858) {a3a5c777-f583-4fef-9380-ab4add1bc2a8}
      7% (2/27) vs.   2% (36/1858) {19503e42-ca3c-4c27-b1e2-9cdb2170ee34} (FlashGot,
Note that this is a "hang" while processing a minidump for a crash.
No, that's not true. The stack you see in the parent is what it always is, the parent writing out its half of the minidump pair. The child minidump is usually more interesting, but in the report from comment 0, the matching child dump is:

Which is not at all useful. It looks like we're missing a module list. Do either of you know if we get useful reports on 10.7 at all?
I should say "useful plugin reports", because clearly the browser process report is fine.
>> Note that this is a "hang" while processing a minidump for a crash.
> No, that's not true.

You're saying the parent process isn't hung, but just behaving as it normally would when the plugin crashes?

If so, then this bug's signature is spurious, and so are most (if not all) of the browser-side signatures of our "top hangs" that are plugin related.  In other words, these signatures don't correspond to hangs.

They're still useful, though, if they can be paired up with stack traces from plugin crashes/hangs.
Steven, I think you misunderstand plugin hang reports. Every plugin hang reports comes with two crash report IDs: we take a snapshot of both the plugin process and the browser process at the time of the hang, and they both end up with a "hang | ..." signature. This is because the cause of the hang may be in either process, so we need often to correlate them both to diagnose the problem.
I understood most of this.  

> and they both end up with a "hang | ..." signature. This is because
> the cause of the hang may be in either process, so we need often to
> correlate them both to diagnose the problem.

I didn't understand this part ... and is it completely true? :-)

In other words,	might some (or even all) plugin	crashes	end up with a
"hang | ..." in	their signature, at least on the browser-process side?

In any case, though, it's (apparently) a mistake to say	that this
bug's signature corresponds to a hang on the browser side.
Currently we don't report any browser-only hangs. We only report plugin hangs. That is going to change soon.

Real plugin crashes *never* have a "hang | " in their summary. Note that plugin hangs appear to the user as a crash (we wait for 45 seconds and then kill the plugin, but the user gets the same plugin frowny-face).
(In reply to comment #3)

> It looks like we're missing a module list. Do either of you know if
> we get useful reports on 10.7 at all?

Looks like we aren't, on any version of OS X 10.7:


(In reply to comment #8)

Looks like Google already filed this issue upstream:
Is this the same issue that results in minidumps not being written out properly on Lion that I see in this log?

Assertion failed: (count && length), function AllocateObjectAndArray, file /builds/slave/m-cen-osx64-dbg/build/toolkit/crashreporter/google-breakpad/src/client/mac/handler/../../../client/minidump_file_writer-inl.h, line 66.
The issue here is that there are empty plugin side crash reports on Mac OS X 10.7.
Severity: critical → normal
Crash Signature: [@ hang | __psynch_mutexwait ] → [@ hang | __psynch_mutexwait ] [@ hang | ]
Component: Plug-ins → Breakpad Integration
Keywords: hang
Product: Core → Toolkit
QA Contact: plugins → breakpad.integration
Hardware: x86 → All
Summary: [10.7] Firefox Crash [@ hang | __psynch_mutexwait ] → [10.7] Empty plugin side crash reports
This appears to have been fixed upstream in Breakpad, although I don't know specifically what fixed it. We should be able to update our Breakpad snapshot to fix this.
Assignee: nobody → ted.mielczarek
Closed: 12 years ago
Depends on: 791775
Resolution: --- → FIXED
It's fixed in versions where hangs are no longer available in crash stats!
Target Milestone: --- → mozilla18
You need to log in before you can comment on or make changes to this bug.