Possibly related to the native library pre-loading fork()'ed process?

I don't think so.
This process forks from the browser process, and commits suicide pretty quickly.

Looking.

I could not reproduce this locally, unfortunately...
A few observations:
- Sandboxed processes are created by the framework, and are isolated processes
- As such, the framework is the one creating and killing them
- A sandboxed process without native code mapped is created by ChildProcessLauncher#warmUp(). There are two places where this is called: from Custom Tabs, and from tabbed mode initialization. The first case should not result in such "dangling" processes. Thinking about it, there may be something suboptimal in the way Custom Tabs deals with this.


Isolated processes should be killed immediately by the framework. See https://android.googlesource.com/platform/frameworks/base/+/master/services/core/java/com/android/server/am/ActivityManagerService.java#20674

// If this is an isolated process, and there are no
// services running in it, then the process is no longer
// needed.  We agressively kill these because we can by
// definition not re-use the same process again, and it is
// good to avoid having whatever code was running in them
// left sitting around after no longer needed.
app.kill("isolated not needed", true);

And indeed, on my device (N6P, Android N):

11-02 16:39:40.699  4935 18617 I ActivityManager: Process com.chrome.dev (pid 31764) has died
11-02 16:39:40.699  4935 18617 D ActivityManager: cleanUpApplicationRecord -- 31764
11-02 16:39:40.700  4935  6810 E ConnectivityService: RemoteException caught trying to send a callback msg for NetworkRequest [ LISTEN id=133, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ]
11-02 16:39:40.703 31804 31804 I cr_ChildProcessService: Destroying ChildProcessService pid=31804
11-02 16:39:40.704  4935 18617 W ActivityManager: Scheduling restart of crashed service com.chrome.dev/org.chromium.chrome.browser.customtabs.CustomTabsConnectionService in 1000ms
11-02 16:39:40.705  4935 18617 I ActivityManager: Killing 31843:com.chrome.dev:sandboxed_process0/u0a116i18 (adj 0): isolated not needed


So, I would say that:
- We (I) should make sure that we're not creating sandboxed processes that we don't use
- The case of "zombie" processes is likely out of our control.


Grace, are you running an experimental version of Android?
If you can reproduce the issue, can you attach a logcat around the time you kill Chrome?

"adb shell dumpsys meminfo" should help as well. In any case, empty isolated processes sounds like a bug, at least with the current stable releases of Android.

I am running NDE63U on Pixel. Here is what I did just now when Chrome Dev is in the background.

09:03:27 ~/Tools/flashstation klobag$adb shell ps | grep chrome
u0_a122   4476  570   1570620 116892 SyS_epoll_ 00e715e484 S com.chrome.dev
u0_i839   8806  570   1141772 17388 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process0
u0_i541   9850  570   1251300 20184 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process0
u0_i908   14340 570   1189844 30912 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process1
u0_a122   14361 570   1272508 67560 SyS_epoll_ 00e715e484 S com.chrome.dev:privileged_process2
u0_i909   14384 570   1250840 79216 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process2
u0_i910   14569 570   1390204 89872 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process3
u0_i888   15340 570   1350500 51908 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process0
u0_i912   17936 570   1377748 80836 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process4
u0_i914   18051 570   1273852 54616 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process2
u0_i915   20552 570   1362968 81696 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process6
u0_i917   26149 570   1140264 25036 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process0
u0_a1     26595 570   1271096 42040 SyS_epoll_ 00e715e484 S com.chrome.canary
u0_a59    31684 570   1387164 57648 SyS_epoll_ 00e715e484 S com.android.chrome
09:03:29 ~/Tools/flashstation klobag$adb shell kill 4476
09:03:49 ~/Tools/flashstation klobag$adb shell ps | grep chrome
u0_i839   8806  570   1141772 17388 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process0
u0_i541   9850  570   1251300 20184 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process0
u0_i888   15340 570   1350500 51908 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process0
u0_i914   18051 570   1273852 54616 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process2
u0_i917   26149 570   1140264 25036 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process0
u0_a1     26595 570   1271096 41392 SyS_epoll_ 00e715e484 S com.chrome.canary
u0_a122   26652 570   1329776 62840          0 00e5759398 R com.chrome.dev
u0_a122   26691 570   1140564 28916 SyS_epoll_ 00e715e484 S com.chrome.dev:privileged_process0
u0_a122   26706 26652 1316900 24588          0 00d213b32c R com.chrome.dev
u0_a59    31684 570   1387164 57728 SyS_epoll_ 00e715e484 S com.android.chrome
09:03:51 ~/Tools/flashstation klobag$adb shell ps | grep chrome
u0_i839   8806  570   1142452 26016 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process0
u0_i541   9850  570   1251456 28252 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process0
u0_i888   15340 570   1350708 59808 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process0
u0_i914   18051 570   1270380 59432 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process2
u0_i917   26149 570   1141476 30960 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process0
u0_a1     26595 570   1272448 45064 SyS_epoll_ 00e715e484 S com.chrome.canary
u0_a122   26652 570   1355584 94736 SyS_epoll_ 00e715e484 S com.chrome.dev
u0_a122   26691 570   1157072 41592 SyS_epoll_ 00e715e484 S com.chrome.dev:privileged_process0
u0_i918   26719 570   1185048 41220 SyS_epoll_ 00e715e484 S com.chrome.dev:sandboxed_process0
u0_a59    31684 570   1388092 61628 SyS_epoll_ 00e715e484 S com.android.chrome

Three observations:
. I "acquired" three more zombie sandboxed process since yesterday.
. Chrome dev, including both GPU and Renderer restarted in the background after I killed the browser process. Odd.
. pid 26706 seems transient, is this the forked browser process you talk about? Is this new?

Here is the bugreport after I did the above operation
https://drive.google.com/open?id=0B9KEwvrWBrVWc1d3MFNmNE9qREU

Thanks!

About your observations:
2. This is probably because GSA is bound to Chrome, so the framework is restarting a crashed service.
3. Yes! Nice to see that you caught it. The parent PID is the browser process, indicating that it has been forked and not created by the framework. It is from https://codereview.chromium.org/1001343002 (March 2015).

Re:
2. when framework restarts us for a crashed service, should we start both GPU and renderer?
3. Thanks. Now I remember that you mentioned this to me in my last visit.

Do you have the multiprocess WebView enabled on your device?

From logcat:

11-02 07:29:11.818  1081  1093 I ActivityManager: Start proc 13966:com.chrome.dev:sandboxed_process0/u0i907 for service com.google.android.apps.inbox/org.chromium.content.app.SandboxedProcessService0

11-02 08:57:02.152  1081  6294 I ActivityManager: Start proc 26149:com.chrome.dev:sandboxed_process0/u0i917 for service com.google.android.calendar/org.chromium.content.app.SandboxedProcessService0


Seems that these processes are actually related to WebView.


Re #6, will investigate. Indeed, there is this in logcat:

11-02 09:03:47.804  1081  6294 W ActivityManager: Scheduling restart of crashed service com.chrome.dev/org.chromium.chrome.browser.customtabs.CustomTabsConnectionService in 1000ms

And, ~1s later:

11-02 09:03:48.928 26652 26652 I cr_LibraryLoader: Time to load native libraries: 168 ms (timestamps 7117-7285)
11-02 09:03:48.929 26652 26652 I cr_LibraryLoader: Expected native library version number "56.0.2900.3", actual native library version number "56.0.2900.3"
11-02 09:03:48.929 26652 26652 I chromium: [INFO:library_loader_hooks.cc(163)] Chromium logging enabled: level = 0, default verbosity = 0
11-02 09:03:48.930 26652 26652 I cr_BrowserStartup: Initializing chromium process, singleProcess=false
11-02 09:03:49.244  1081  2685 I ActivityManager: Start proc 26691:com.chrome.dev:privileged_process0/u0a122 for service com.chrome.dev/org.chromium.content.app.PrivilegedProcessService0
11-02 09:03:49.257 26652 26684 I cr_LibraryLoader: Using linker: org.chromium.base.library_loader.ModernLinker
11-02 09:03:49.313 26691 26691 I cr_ChildProcessService: Creating new ChildProcessService pid=26691

Good call. I do have multi-process WebView enabled. +Bo and Torne to see whether we should distinguish them in the process name.

+rsesek

In multiprocess webview the current implementation names the service after the package using the WebView as you see in the log: "com.google.android.apps.inbox/org.chromium.content.app.SandboxedProcessService0" but does not change the process name which is just derived using the usual algorithm from the package. The process names being non-unique doesn't cause the system any actual problem here, but it does confuse humans.

Robert, maybe we should mangle the process names? This seems likely to continue to confuse people.

Yes, we should change the process name. I had a CL to do that in N but it didn't make the cut. I'll rebase it and we'll get it in a future platform release.

Thanks for the fast response.

lizeb@, feel free to close this or assign to rsesek@. And open another one to track #6 issue.

Closing the bug.
Regarding the comment in #6, GSA no longer restarts Chrome when it was killed by the framework.