Currently we will crash when Nuwa is enabled because Nuwa doesn't know the mOpener.

The another problem then mOpener is that 1. To embed a remote iframe into Web App on content process. 2. [1] will be reached for loading a remote page. 3. Then Nuwa will be tried to launch again and [1] will be called 4. Finally seccmp kills that process bcause a illegal syscall for setsocketopt. I think we need to make sure the check[1] should be performed by b2g process only. Because the real new content process is created by b2g process. [1] http://dxr.mozilla.org/mozilla-central/source/content/base/src/nsFrameLoader.cpp?from=nsframeloader.cpp&case=true#478 [2] http://dxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/client/linux/crash_generation/crash_generation_server.cc#241

Move to 2.1 Sprint 2.

The browser app creates two remote iframe at launch time. When nuwa is enabled ContentParent::GetNewOrUsed will return nullptr when we can't fork preallocate process fast enough. https://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp?rev=3231ca1bb833&mark=726-731#l726 If we fix RecvCreateChildProcess to return nullptr instead of crash we will hit another problem: https://mxr.mozilla.org/mozilla-central/source/content/base/src/nsFrameLoader.cpp?rev=3231ca1bb833&mark=475-481#l475 The nsFrameLoader will wait until the preallocated process is ready then try again but that information is not currently available to the content process.

Another case, the mOpener of Nuwa allocated process is not initialized #0 mozilla::dom::ContentParent::TransformPreallocatedIntoBrowser (this=0xa94ad400) at ../../../gecko/dom/ipc/ContentParent.cpp:1316 #1 0xb56e5e46 in mozilla::dom::ContentParent::GetNewOrUsed (aForBrowserElement=<optimized out>, aPriority=mozilla::hal::PROCESS_PRIORITY_FOREGROUND, aOpener=0xafd2bc00) at ../../../gecko/dom/ipc/ContentParent.cpp:724 #2 0xb56e5ee2 in mozilla::dom::ContentParent::RecvCreateChildProcess (this=0xafd2bc00, aContext=<optimized out>, aPriority=<optimized out>, aId=0xbe902570, aIsForApp=0xbe902557, aIsForBrowser=0xbe902558) at ../../../gecko/dom/ipc/ContentParent.cpp:826 #3 0xb5111074 in mozilla::dom::PContentParent::OnMessageReceived (this=0xafd2bc00, __msg=<optimized out>, __reply=@0xbe902640) at PContentParent.cpp:4199 #4 0xb50cbb3c in mozilla::ipc::MessageChannel::DispatchSyncMessage (this=0xafd2bc30, aMsg=...) at ../../../gecko/ipc/glue/MessageChannel.cpp:1115 #5 0xb50d0a72 in mozilla::ipc::MessageChannel::OnMaybeDequeueOne (this=<optimized out>) at ../../../gecko/ipc/glue/MessageChannel.cpp:1087 #6 0xb4f619e2 in DispatchToMethod<FdWatcher, void (FdWatcher::*)()> (method=(void (FdWatcher::*)(FdWatcher * const)) 0xb50d09fb <mozilla::ipc::MessageChannel::OnMaybeDequeueOne()>, obj=<optimized out>, arg=<optimized out>) at ../../../gecko/ipc/chromium/src/base/tuple.h:383 #7 RunnableMethod<FdWatcher, void (FdWatcher::*)(), Tuple0>::Run (this=<optimized out>) at ../../../gecko/ipc/chromium/src/base/task.h:307 #8 0xb50c9fec in Run (this=<optimized out>) at ../../dist/include/mozilla/ipc/MessageChannel.h:397 #9 mozilla::ipc::MessageChannel::DequeueTask::Run (this=<optimized out>) at ../../dist/include/mozilla/ipc/MessageChannel.h:414 #10 0xb50c1b38 in MessageLoop::RunTask (this=0xb6b7a1a0, task=0xa9f5d408) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:357 #11 0xb50c3afe in MessageLoop::DeferOrRunPendingTask (this=<optimized out>, pending_task=<optimized out>) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:365 #12 0xb50c56a8 in DoWork (this=<optimized out>) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:443 #13 MessageLoop::DoWork (this=0xb6b7a1a0) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:422 #14 0xb50ca6b8 in mozilla::ipc::DoWorkRunnable::Run (this=<optimized out>) at ../../../gecko/ipc/glue/MessagePump.cpp:233 #15 0xb4f841ea in ProcessNextEvent (aResult=0xbe90275f, aMayWait=<optimized out>, this=0xb6b024e0) at ../../../gecko/xpcom/threads/nsThread.cpp:770 #16 nsThread::ProcessNextEvent (this=0xb6b024e0, aMayWait=<optimized out>, aResult=0xbe90275f) at ../../../gecko/xpcom/threads/nsThread.cpp:686 #17 0xb4f923aa in NS_ProcessNextEvent (aThread=<optimized out>, aMayWait=<optimized out>) at /home/kanru/mozilla/B2G/gecko/xpcom/glue/nsThreadUtils.cpp:265 #18 0xb50cccee in mozilla::ipc::MessagePump::Run (this=0xb6b01f40, aDelegate=0xb6b7a1a0) at ../../../gecko/ipc/glue/MessagePump.cpp:140 #19 0xb50c1ac6 in MessageLoop::RunInternal (this=<optimized out>) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:229 #20 0xb50c1b78 in RunHandler (this=0xb6b7a1a0) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:222 #21 MessageLoop::Run (this=0xb6b7a1a0) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:196 #22 0xb5768a42 in nsBaseAppShell::Run (this=0xb34efd00) at ../../../gecko/widget/xpwidgets/nsBaseAppShell.cpp:164 #23 0xb5bbd8ae in nsAppStartup::Run (this=0xb2267ee0) at ../../../../gecko/toolkit/components/startup/nsAppStartup.cpp:278 #24 0xb5bd02f6 in XREMain::XRE_mainRun (this=0xbe9028c4) at ../../../gecko/toolkit/xre/nsAppRunner.cpp:4021 #25 0xb5bd14f4 in XREMain::XRE_main (this=0xbe9028c4, argc=<optimized out>, argv=<optimized out>, aAppData=<optimized out>) at ../../../gecko/toolkit/xre/nsAppRunner.cpp:4092 #26 0xb5bd1650 in XRE_main (argc=1, argv=0xb6b3b178, aAppData=0x248f4, aFlags=<optimized out>) at ../../../gecko/toolkit/xre/nsAppRunner.cpp:4306 #27 0x0000b0fc in do_main (argc=1, argv=0xb6b3b178) at ../../../gecko/b2g/app/nsBrowserApp.cpp:164 #28 0x0000b1f6 in b2g_main (argc=1, argv=0xbe903af4) at ../../../gecko/b2g/app/nsBrowserApp.cpp:290 #29 0x0000afb2 in RunProcesses (argv=0xbe903af4, argc=1) at ../../../gecko/b2g/app/B2GLoader.cpp:221 #30 main (argc=1, argv=0xbe903af4) at ../../../gecko/b2g/app/B2GLoader.cpp:247

After bug 1033618 we don't wait Nuwa preallocated process but fork a new process from main process directly. The DelayedStartLoadingRunnable actually delayed the URI loading until the preallocated process is ready. Remove the delayed task so we could load the URI immediately. I wonder if we should also remove PreallocatedProcessReady() and RunAfterPreallocatedProcessReady together since nobody uses them.

This makes the browser process allocation behavior align to the app process allocation.

Move to v2.1 sprint 3.

Comment on attachment 8473536 [details] [diff] [review] Part 1. Don't wait preallocated process in nsFrameLloader. Review of attachment 8473536 [details] [diff] [review]: ----------------------------------------------------------------- This was done in bug 1057065.

Confirmed with EM/EPM, and this can be landed before FL.

remote: https://hg.mozilla.org/integration/b2g-inbound/rev/d9f10f4f4072 remote: https://hg.mozilla.org/integration/b2g-inbound/rev/5c2161c6a4bc remote: https://hg.mozilla.org/integration/b2g-inbound/rev/d66ca638bd7f remote: https://hg.mozilla.org/integration/b2g-inbound/rev/a34005d5bfa0

https://hg.mozilla.org/mozilla-central/rev/d9f10f4f4072 https://hg.mozilla.org/mozilla-central/rev/5c2161c6a4bc https://hg.mozilla.org/mozilla-central/rev/d66ca638bd7f https://hg.mozilla.org/mozilla-central/rev/a34005d5bfa0