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

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

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

Okay, nom removed until we know more.

Subsumed by bug 811636.