Closed Bug 1040561 Opened 6 years ago Closed 6 years ago

Nested-oop does not works with Nuwa


(Core :: DOM: Core & HTML, defect)

Not set





(Reporter: kanru, Assigned: kanru)



(Whiteboard: [nested-oop][FT:Stream3])


(6 files)

Currently we will crash when Nuwa is enabled because Nuwa doesn't know the mOpener.
Duplicate of this bug: 1041417
feature-b2g: --- → 2.1
Whiteboard: [nested-oop][FT:Stream3]
Target Milestone: --- → 2.1 S1 (1aug)
Blocks: 1033984
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.


Move to 2.1 Sprint 2.
Target Milestone: 2.1 S1 (1aug) → 2.1 S2 (15aug)
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.

If we fix RecvCreateChildProcess to return nullptr instead of crash we will hit another problem:

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/
#11 0xb50c3afe in MessageLoop::DeferOrRunPendingTask (this=<optimized out>, pending_task=<optimized out>) at ../../../gecko/ipc/chromium/src/base/
#12 0xb50c56a8 in DoWork (this=<optimized out>) at ../../../gecko/ipc/chromium/src/base/
#13 MessageLoop::DoWork (this=0xb6b7a1a0) at ../../../gecko/ipc/chromium/src/base/
#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/
#20 0xb50c1b78 in RunHandler (this=0xb6b7a1a0) at ../../../gecko/ipc/chromium/src/base/
#21 MessageLoop::Run (this=0xb6b7a1a0) at ../../../gecko/ipc/chromium/src/base/
#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

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.
Attachment #8473536 - Flags: review?(khuey)
This makes the browser process allocation behavior align to the app
process allocation.
Attachment #8473537 - Flags: review?(khuey)
Attachment #8473537 - Attachment description: Don't wait Nuwa preallocated process when allocating new browser process → Part 2. Don't wait Nuwa preallocated process when allocating new browser process
Attachment #8473538 - Attachment description: Return nullptr when CreateContentBridgeParent fails. → Part 3. Return nullptr when CreateContentBridgeParent fails.
Move to v2.1 sprint 3.
Target Milestone: 2.1 S2 (15aug) → 2.1 S3 (29aug)
Depends on: 1057230
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.
Attachment #8473536 - Flags: review?(khuey)
Confirmed with EM/EPM, and this can be landed before FL.
feature-b2g: 2.1 → 2.2?
No longer blocks: 1033984
Target Milestone: 2.1 S3 (29aug) → ---
Blocks: 1057230
No longer depends on: 1057230
feature-b2g: 2.2? → ---
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.