Closed
Bug 691424
Opened 13 years ago
Closed 13 years ago
crash [@ mozilla::plugins::PluginModuleParent::WriteExtraDataForMinidump]
Categories
(Core :: IPC, defect)
Tracking
()
RESOLVED
FIXED
mozilla10
People
(Reporter: nhirata, Unassigned)
References
Details
(Keywords: crash, topcrash, Whiteboard: [mobile-crash][ironic])
Crash Data
Attachments
(1 file, 1 obsolete file)
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
Reporter | ||
Updated•13 years ago
|
Reporter | ||
Comment 1•13 years ago
|
||
# 1 crash in 10 (nightly)
Comment 2•13 years ago
|
||
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 :(
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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.
Reporter | ||
Comment 8•13 years ago
|
||
Looks like this crash occured on the 10/15 build : https://crash-stats.mozilla.com/report/index/10860c97-2e90-4d37-b36c-f102a2111015
Comment 9•13 years ago
|
||
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•13 years ago
|
||
I don't understand any of what you just said. You can fix this any way you want.
Comment 11•13 years ago
|
||
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.
Attachment #568129 -
Flags: review?(benjamin)
Comment 12•13 years ago
|
||
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.
Attachment #568129 -
Flags: review?(benjamin)
Comment 13•13 years ago
|
||
Attachment #568137 -
Flags: review?(benjamin)
Updated•13 years ago
|
Attachment #568129 -
Attachment is obsolete: true
Updated•13 years ago
|
Attachment #568137 -
Flags: review?(benjamin) → review+
Comment 15•13 years ago
|
||
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•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/54dde714ef41
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
Updated•13 years ago
|
Whiteboard: [mobile-crash] → [mobile-crash][ironic]
You need to log in
before you can comment on or make changes to this bug.
Description
•