Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 691424 - crash [@ mozilla::plugins::PluginModuleParent::WriteExtraDataForMinidump]
: crash [@ mozilla::plugins::PluginModuleParent::WriteExtraDataForMinidump]
: crash, topcrash
Product: Core
Classification: Components
Component: IPC (show other bugs)
: Trunk
: ARM Android
: -- critical (vote)
: mozilla10
Assigned To: Nobody; OK to take it and work on it
: Bill McCloskey (:billm)
Depends on:
Blocks: 581341
  Show dependency treegraph
Reported: 2011-10-03 11:19 PDT by Naoki Hirata :nhirata (please use needinfo instead of cc)
Modified: 2011-10-24 00:27 PDT (History)
12 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Ensure that plugin processes that can't create a crash reporter actor abort the plugin creation process. (2.05 KB, patch)
2011-10-19 11:30 PDT, Josh Matthews [:jdm]
no flags Details | Diff | Splinter Review
Ensure that plugin processes that can't create a crash reporter actor abort the plugin creation process. (2.69 KB, patch)
2011-10-19 11:37 PDT, Josh Matthews [:jdm]
benjamin: review+
Details | Diff | Splinter Review

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

Same crashing as Bug 668385 ?
More crashes :
Comment 1 Naoki Hirata :nhirata (please use needinfo instead of cc) 2011-10-03 11:21:58 PDT
# 1 crash in 10 (nightly)
Comment 2 Josh Matthews [:jdm] 2011-10-03 12:56:12 PDT
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 2011-10-04 11:32:14 PDT
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] 2011-10-08 13:24:21 PDT
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] 2011-10-08 13:32:06 PDT
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] 2011-10-13 12:14:49 PDT
The plugin is failing to load when calling, since GetNewPluginLibrary checks if it should run OOP, then does so ( 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] 2011-10-13 12:32:34 PDT
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) 2011-10-17 11:40:19 PDT
Looks like this crash occured on the 10/15 build :
Comment 9 Josh Matthews [:jdm] 2011-10-17 11:58:51 PDT
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 Ted Mielczarek [:ted.mielczarek] 2011-10-17 13:02:56 PDT
I don't understand any of what you just said. You can fix this any way you want.
Comment 11 Josh Matthews [:jdm] 2011-10-19 11:30:46 PDT
Created attachment 568129 [details] [diff] [review]
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] 2011-10-19 11:34:39 PDT
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] 2011-10-19 11:37:49 PDT
Created attachment 568137 [details] [diff] [review]
Ensure that plugin processes that can't create a crash reporter actor abort the plugin creation process.
Comment 15 Martijn Wargers [:mwargers] (not working for Mozilla) 2011-10-19 13:08:38 PDT
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] 2011-10-20 03:01:52 PDT

Note You need to log in before you can comment on or make changes to this bug.