778025 - Crashing on SendPBrowserConstructor when content process is force-killed

Status: RESOLVED DUPLICATE of bug 811636

(Core :: IPC, defect)

Description

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

Attachment: Patch that triggers crash

With the attached patch (after bug 671196), we crash in the master process with the following stack.

This "shouldn't happen", because the process initialization happens in the same event-loop iteration as the PBrowser ctor.  We're probably missing an error return or the channel state is getting confused.

#5  0x00007f9d5843c44d in mozalloc_abort (msg=0x7fff72304630 "[Parent 19287] ###!!! ABORT: not on worker thread!: 'mWorkerLoop == MessageLoop::current()', file ../../dist/include/mozilla/ipc/AsyncChannel.h, line 207") at /home/cjones/mozilla/inbound/memory/mozalloc/mozalloc_abort.cpp:23
#6  0x00007f9d561ba55c in Abort (aMsg=0x7fff72304630 "[Parent 19287] ###!!! ABORT: not on worker thread!: 'mWorkerLoop == MessageLoop::current()', file ../../dist/include/mozilla/ipc/AsyncChannel.h, line 207") at /home/cjones/mozilla/inbound/xpcom/base/nsDebugImpl.cpp:423
#7  0x00007f9d561ba460 in NS_DebugBreak_P (aSeverity=3, aStr=0x7f9d5728100e "not on worker thread!", aExpr=0x7f9d57280fe8 "mWorkerLoop == MessageLoop::current()", aFile=0x7f9d57280ee0 "../../dist/include/mozilla/ipc/AsyncChannel.h", aLine=207) at /home/cjones/mozilla/inbound/xpcom/base/nsDebugImpl.cpp:380
#8  0x00007f9d55e9158d in mozilla::ipc::AsyncChannel::AssertWorkerThread (this=0x24f9220) at ../../dist/include/mozilla/ipc/AsyncChannel.h:206
#9  0x00007f9d55e9d7a4 in mozilla::ipc::RPCChannel::CxxStackFrame::CxxStackFrame (this=0x7fff72304b30, that=..., direction=mozilla::ipc::RPCChannel::OUT_MESSAGE, msg=0x7fff72304ae0) at ../../dist/include/mozilla/ipc/RPCChannel.h:247
#10 0x00007f9d55e9e0ae in mozilla::ipc::RPCChannel::Send (this=0x24f9220, msg=0x3658a50) at /home/cjones/mozilla/inbound/ipc/glue/RPCChannel.cpp:109
#11 0x00007f9d55f0a92f in mozilla::dom::PContentParent::SendPBrowserConstructor (this=0x24f9210, actor=0x3506940, chromeFlags=@0x7fff72304d1c: 0, id=..., isBrowserElement=@0x7fff72304bf4: false) at /home/cjones/mozilla/2gaia-dbg/ipc/ipdl/PContentParent.cpp:425
#12 0x00007f9d55e4d7d7 in mozilla::dom::ContentParent::CreateBrowser (aApp=0x1ddd350, aIsBrowserElement=false, aProcess=0x7fff72304f80) at /home/cjones/mozilla/inbound/dom/ipc/ContentParent.cpp:227
#13 0x00007f9d54e3879b in nsFrameLoader::TryRemoteBrowser (this=0x22bbd60) at /home/cjones/mozilla/inbound/content/base/src/nsFrameLoader.cpp:2007
#14 0x00007f9d54e319b3 in nsFrameLoader::ReallyStartLoadingInternal (this=0x22bbd60) at /home/cjones/mozilla/inbound/content/base/src/nsFrameLoader.cpp:421
#15 0x00007f9d54e31892 in nsFrameLoader::ReallyStartLoading (this=0x22bbd60) at /home/cjones/mozilla/inbound/content/base/src/nsFrameLoader.cpp:401
#16 0x00007f9d54e06c55 in nsDocument::MaybeInitializeFinalizeFrameLoaders (this=0x223dda0) at /home/cjones/mozilla/inbound/content/base/src/nsDocument.cpp:5441
#17 0x00007f9d54e247a1 in nsRunnableMethodImpl<void (nsDocument::*)(), true>::Run (this=0x2052030) at ../../../dist/include/nsThreadUtils.h:349
#18 0x00007f9d54db912f in nsContentUtils::AddScriptRunner (aRunnable=0x2052030) at /home/cjones/mozilla/inbound/content/base/src/nsContentUtils.cpp:4916
#19 0x00007f9d54e06948 in nsDocument::InitializeFrameLoader (this=0x223dda0, aLoader=0x22bbd60) at /home/cjones/mozilla/inbound/content/base/src/nsDocument.cpp:5387
#20 0x00007f9d54e3183c in nsFrameLoader::LoadURI (this=0x22bbd60, aURI=0x3024dc0) at /home/cjones/mozilla/inbound/content/base/src/nsFrameLoader.cpp:391
#21 0x00007f9d54e315bb in nsFrameLoader::LoadFrame (this=0x22bbd60) at /home/cjones/mozilla/inbound/content/base/src/nsFrameLoader.cpp:355
#22 0x00007f9d55013145 in nsGenericHTMLFrameElement::LoadSrc (this=0x27cf7c0) at /home/cjones/mozilla/inbound/content/html/content/src/nsGenericHTMLFrameElement.cpp:153

Comment 1

[Andrew Overholt [:overholt]]

Is the content process getting killed likely enough that we should block on this, Chris?

Comment 2

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

This is something we should fix but we don't have evidence to know whether it should block or not.

Comment 3

[Andrew Overholt [:overholt]]

Okay, nom removed until we know more.

Comment 4

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

Subsumed by bug 811636.