691424 - crash [@ mozilla::plugins::PluginModuleParent::WriteExtraDataForMinidump]

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

This bug was filed from the Socorro interface and is 
report bp-3d2c4244-45ba-42dc-9fb4-dbcf32111002 .
============================================================= 
Frame 	Module 	Signature [Expand] 	Source
0 	libxul.so 	mozilla::plugins::PluginModuleParent::WriteExtraDataForMinidump 	nsTSubstring.h:218
1 	libxul.so 	mozilla::plugins::PluginModuleParent::ActorDestroy 	nsCOMPtr.h:466
2 	libxul.so 	mozilla::plugins::PPluginModuleParent::DestroySubtree 	obj-firefox/ipc/ipdl/PPluginModuleParent.cpp:1560
3 	libxul.so 	mozilla::plugins::PPluginModuleParent::OnChannelError 	obj-firefox/ipc/ipdl/PPluginModuleParent.cpp:1245
4 	libxul.so 	mozilla::ipc::AsyncChannel::NotifyMaybeChannelError 	ipc/glue/AsyncChannel.cpp:380
5 	libxul.so 	mozilla::ipc::AsyncChannel::Close 	Mutex.h:106
6 	libxul.so 	mozilla::plugins::PPluginModuleParent::Close 	obj-firefox/ipc/ipdl/PPluginModuleParent.cpp:113
7 	libxul.so 	mozilla::plugins::PluginModuleParent::NP_Shutdown 	dom/plugins/ipc/PluginModuleParent.cpp:814
8 	libxul.so 	mozilla::plugins::PluginModuleParent::~PluginModuleParent 	dom/plugins/ipc/PluginModuleParent.cpp:162
9 	libxul.so 	mozilla::plugins::PluginModuleParent::~PluginModuleParent 	mozalloc.h:253
10 	libxul.so 	nsNPAPIPlugin::~nsNPAPIPlugin 	dom/plugins/base/nsNPAPIPlugin.cpp:261
11 	libxul.so 	nsNPAPIPlugin::~nsNPAPIPlugin 	mozalloc.h:253
12 	libxul.so 	nsNPAPIPlugin::Release 	dom/plugins/base/nsNPAPIPlugin.cpp:247
13 	libxul.so 	nsNPAPIPlugin::CreatePlugin 	xpcom/base/nsAutoPtr.h:907
14 	libxul.so 	nsPluginHost::EnsurePluginLoaded 	dom/plugins/base/nsPluginHost.cpp:1656
15 	libxul.so 	nsPluginHost::GetPlugin 	dom/plugins/base/nsPluginHost.cpp:1688
16 	libxul.so 	nsPluginHost::TrySetUpPluginInstance 	xpcom/base/nsAutoPtr.h:1036
17 	libxul.so 	nsPluginHost::SetUpPluginInstance 	dom/plugins/base/nsPluginHost.cpp:1190
18 	libxul.so 	nsPluginStreamListenerPeer::OnStartRequest 	dom/plugins/base/nsPluginStreamListenerPeer.cpp:657
19 	libxul.so 	nsObjectLoadingContent::OnStartRequest 	content/base/src/nsObjectLoadingContent.cpp:745
20 	libxul.so 	mozilla::net::HttpChannelChild::OnStartRequest 	netwerk/protocol/http/HttpChannelChild.cpp:309
21 	libxul.so 	mozilla::net::HttpChannelChild::RecvOnStartRequest 	netwerk/protocol/http/HttpChannelChild.cpp:266
22 	libxul.so 	mozilla::net::PHttpChannelChild::OnMessageReceived 	obj-firefox/ipc/ipdl/PHttpChannelChild.cpp:448
23 	libxul.so 	mozilla::dom::PContentChild::OnMessageReceived 	obj-firefox/ipc/ipdl/PContentChild.cpp:1312
24 	libxul.so 	mozilla::ipc::AsyncChannel::OnDispatchMessage 	ipc/glue/AsyncChannel.cpp:294
25 	libxul.so 	mozilla::ipc::RPCChannel::OnMaybeDequeueOne 	ipc/glue/RPCChannel.cpp:435
26 	libxul.so 	RunnableMethod<mozilla::ipc::RPCChannel, bool , Tuple0>::Run 	ipc/chromium/src/base/task.h:308
27 	libxul.so 	mozilla::ipc::RPCChannel::DequeueTask::Run 	RPCChannel.h:487
28 	libxul.so 	MessageLoop::RunTask 	ipc/chromium/src/base/message_loop.cc:319
29 	libxul.so 	MessageLoop::DeferOrRunPendingTask 	ipc/chromium/src/base/message_loop.cc:329
30 	libxul.so 	MessageLoop::DoWork 	ipc/chromium/src/base/message_loop.cc:426
31 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:115
32 	libxul.so 	mozilla::ipc::MessagePumpForChildProcess::Run 	ipc/glue/MessagePump.cpp:230
33 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:209
34 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:487
35 	libxul.so 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:191
36 	libxul.so 	XRE_RunAppShell 	toolkit/xre/nsEmbedFunctions.cpp:677
37 	libxul.so 	mozilla::ipc::MessagePumpForChildProcess::Run 	ipc/glue/MessagePump.cpp:222
38 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:209
39 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:487
40 	libxul.so 	XRE_InitChildProcess 	nsAutoPtr.h:155
41 	libmozutils.so 	ChildProcessInit 	other-licenses/android/APKOpen.cpp:790
42 	plugin-container 	main 	ipc/app/MozillaRuntimeMainAndroid.cpp:69
43 	libc.so 	__libc_init 	
44 		@0xb0004592

Same crashing as Bug 668385 ?
More crashes : https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2011-10-03%2009%3A00%3A00&signature=mozilla%3A%3Aplugins%3A%3APluginModuleParent%3A%3AWriteExtraDataForMinidump&version=Fennec%3A10.0a1

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

# 1 crash in 10 (nightly)

Comment 2

[Josh Matthews [:jdm]]

Oh joy, this patch went in just in time for plugins to start working in content processes, or not working I guess, according to the stack trace. This is going to require some thinking about how these actors should interact, since we're apparently trying to make use of PluginModuleParent (and associated CrashReporterParent) in the content process :(

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

My understanding of the android plugin code was that it had to run in the chrome process.  This running in content looks like a bug.

Comment 4

[Josh Matthews [:jdm]]

I believe what changed is PluginModuleParent::ActorDestroy, and CrashReporter::TakeMinidumpForChild. The latter used to be called by the former, but it would return false because CrashReporter::GetEnabled used to return false in content processes. ActorDestroy would just continue on its merry way in that case. However, now I made it unconditionally try to use a CrashReporterParent actor, and that's causing trouble. Do we actually claim to support plugins in Fennec on any platform? Could we just switch the dom.ipc.plugins.enabled preference and avoid the whole issue?

Comment 5

[Josh Matthews [:jdm]]

Actually switching dom.ipc.plugins.enabled might not fix it. I'm still trying to figure out how the plugin loading code works.

Comment 6

[Josh Matthews [:jdm]]

The plugin is failing to load when calling http://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsNPAPIPlugin.cpp#l482, since GetNewPluginLibrary checks if it should run OOP, then does so (http://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsNPAPIPlugin.cpp#461). However, the plugin process fails (maybe because we try to create a CrashReporter actor without IPDL believing we should?), and we wind up in this bad situation. So, quick fix: turn off dom.ipc.plugins.enabled and see what happens?

Comment 7

[Josh Matthews [:jdm]]

Oh, looks like the pref was recently switched to false from true. If my theory is correct, we should stop seeing this crash on nightlies from this time forward.

Comment 8

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Looks like this crash occured on the 10/15 build : 
https://crash-stats.mozilla.com/report/index/10860c97-2e90-4d37-b36c-f102a2111015

Comment 9

[Josh Matthews [:jdm]]

So my analysis was incorrect. GetNewPluginLibrary succeeds, but I'm still not sure why we get a PluginModuleParent back instead of an in-process plugin library. All signs point to RunPluginAsOOP returning false from reading the code. Should I just patch this to not report a crash if we don't have a crash report actor from the child, since this is currently breaking the whole process separation guarantee on both mobile and desktop?

Comment 10

[(not currently active) Ted Mielczarek]

I don't understand any of what you just said. You can fix this any way you want.

Comment 11

[Josh Matthews [:jdm]]

Attachment: Ensure that plugin processes that can't create a crash reporter actor abort the plugin creation process.

I still can't figure out why this is being triggered on mobile, which supposedly has dom.ipc.plugins.enabled set to false. However, this should stop those crashes, and the ones on desktop that seem to be occurring for the same reason.

Comment 12

[Josh Matthews [:jdm]]

Comment on attachment 568129 [details] [diff] [review]
Ensure that plugin processes that can't create a crash reporter actor abort the plugin creation process.

Sorry, need to qref.

Comment 13

[Josh Matthews [:jdm]]

Attachment: Ensure that plugin processes that can't create a crash reporter actor abort the plugin creation process.

Comment 14

[Josh Matthews [:jdm]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/54dde714ef41

Comment 15

[Martijn Wargers (dead)]

Ok, I could reproduce this crash with the dom.ipc.plugins.enabled pref set to true.
With the pref set to false, I couldn't reproduce it.

Comment 16

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/54dde714ef41