When debugging content process startup stuff, it's useful to set dom.ipc.processCount=1 and run with MOZ_DEBUG_CHILD_PROCESS=1 to be able to attach the debugger to the content process. But it seems like dom.ipc.processCount=1 only restricts some kinds of content processes and still basically creates a bunch of content processes on demand, and makes debugging complicated. For example, below is the pstree snippet from a local m-c build using dom.ipc.processCount=1 in which I loaded two tabs (about:config and a file:/// URL). It shows three (!) content processes and it's really annoying to try to figure out which one I need to attach to. | | \-+- 86760 kats /Users/kats/zspace/mozilla-w2/obj-host-prof/dist/Nightly.app/Contents/MacOS/firefox -no-remote -foreground -profile /Users/kats/zspace/mozilla-w2/obj-host-prof/tmp/profile-default | | |--- 86761 kats /Users/kats/zspace/mozilla-w2/obj-host-prof/dist/Nightly.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 169846 -schedulerPrefs 0001,2 -parentBuildID 20181018094803 -appdir /Users/kats/zspace/mozilla-w2/obj-host-prof/dist/Nightly.app/Contents/Resources/browser -profile /Users/kats/zspace/mozilla-w2/obj-host-prof/tmp/profile-default 86760 org.mozilla.machname.1026751484 tab | | |--- 86762 kats /Users/kats/zspace/mozilla-w2/obj-host-prof/dist/Nightly.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container -childID 2 -isForBrowser -prefsLen 176 -prefMapSize 169846 -schedulerPrefs 0001,2 -parentBuildID 20181018094803 -appdir /Users/kats/zspace/mozilla-w2/obj-host-prof/dist/Nightly.app/Contents/Resources/browser -profile /Users/kats/zspace/mozilla-w2/obj-host-prof/tmp/profile-default 86760 org.mozilla.machname.1953354886 tab | | \--- 86764 kats /Users/kats/zspace/mozilla-w2/obj-host-prof/dist/Nightly.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container -childID 3 -isForBrowser -prefsLen 6102 -prefMapSize 169846 -schedulerPrefs 0001,2 -parentBuildID 20181018094803 -appdir /Users/kats/zspace/mozilla-w2/obj-host-prof/dist/Nightly.app/Contents/Resources/browser -profile /Users/kats/zspace/mozilla-w2/obj-host-prof/tmp/profile-default 86760 org.mozilla.machname.1379421378 tab
I think that's expected. It is really restricting the number of processes in each subtype. The file URLs are in their own process, non-file processes are going to be in another tab, and maybe you have a GPU process or a preallocated process. about:memory can show you PIDs, or you can hover over the tabs.
> about:memory can show you PIDs, or you can hover over the tabs. This assumes I'm not debugging a content-process startup crash, though. Which is the case I have trouble with. Is there some other way to collapse all the different subtypes into a single content process? Some magic environment variable maybe?
Not that I know of. Jed, any ideas?
The last argument is the process type; "tab" means a content process, so none of those is a GPU process (which is enabled only on Windows at the moment). Also, none of those is a preallocated process, because it respects dom.ipc.processCount (sometimes a little too carefully: see bug 1492624). Content process subtypes exist mainly for security reasons: * The file:/// process can read arbitrary files, which isn't allowed in the normal content process sandbox. * The WebExtension process can do whatever any extension can do, which is a lot (e.g., native messaging). * The "privileged" type is used for some about: pages; I'm a little unclear on the details, but bug 1469072 added it. I'm not aware of a way to ignore subtypes and use a single process for everything; if that existed, it would need to turn off sandboxing and also bypass any subtype-based security checks that ContentParent is doing (and, post-Fission, origin checks). It looks like the child process doesn't know which type it is until ContentChild::RecvRemoteType, so it can't print that in the "CHILDCHILDCHILDCHILD debug me" message; however, the parent process could log the (pid, subtype) pair when it gets the pid. (Note: Launching is about to undergo some changes in bug 1446161, so any patches to that part of ContentParent as it exists now will have a nontrivial merge.) The other thing I'd suggest here is rr, if the bug reproduces on Linux.  https://searchfox.org/mozilla-central/rev/c56977420df7a1b692ce0f7e499ddb364d9fd7b2/dom/ipc/ContentParent.h#43-46  https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging
Logging the (pid, subtype) in the parent would probably be good enough, as long as the subtype is unique enough to distinguish between the three content processes in my example above. Maybe we can do that here after bug 1446161 lands?
Depends on: 1446161
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.