I tried to double click on those two tabs in order to make Chrome focus them.
One of them brought up an Aw, snap! tab (so it is not really resurrected).
The other one started loading immediately.

So the Chrome task manager basically reports (and only when you close and open it) that dead processes are still alive when they are, in fact, still dead.

This is affecting the performance of the system and hogs up the memory.

I have a window with about twenty to thirty tabs (that I killed or that were not yet loaded) and every few hours, the processes of a lot of them are resurrected in the background, but going to the tabs show "Aw, snap!" (or reloads the tab).
It happens with other windows, but resurrecting twenty processes takes a lot of memory and it slows the system down.

I think it started to become really bad in Chrome 58.

chrisha@: Can you triage the resurrected process aspect of this?  (And is there a component to add for that?)

nick@: Can you and Chuck triage the task manager aspect of this, where the processes aren't showing up?

+lukasza, fyi

Thanks for the repro instructions. Do I need to enable the "Automatic tab discarding" feature via about:flags as well, or does discarding mean something different here? If so let's edit the description to reflect that.

https://codereview.chromium.org/2857263003 -- which landed after this bug was originally reported -- may have affected the TaskManager's behavior in this scenario.

I wasn't able to repro on my desktop, even with the "Automatic tab discarding" flag enabled and a compile running in the background.

To solve the TaskManager visibility issue, we need to determine the mechanism by which the tabs are reloaded.

I believe "Automatic tag discarding" is set to "Default" and I always experience this feature, so it must have been enabled by a field trial (or by default).

While there is some relation to tab discarding, I am not sure tab discarding is the main culprit here (unless it thinks that the user tried to interact with some tab and so resurrects its process somewhat but not telling anyone about it). Like I mentioned, it even happens to tabs I have explicitly killed (killed the process, but did not close the tab).

One thing worth noting is that those processes do not seem to act like regular renderer processes. They are usually small (2 - 6 MB of memory in the Chrome task manager), regardless of their original content (for example, if GMail or the WHATWG HTML specification were really running in a renderer process, I would have expected them to consume 100+ MB of memory, but I think they do not).

Thanks for the pointers. I just managed to get a repro using M58, and am reducing it now. The smoking gun is a process that shows up in the task manager, but which still shows a sad tab in the tab strip when you double-click the row.

Yes, that is the bumming one. :(

Here's a simplified repro that works in M58 using only two tabs.

1. Open a new Incognito browser window via Ctrl+Shift+N. Call the initial tab "Tab A".
2. Navigate Tab A to http://csreis.github.io/tests/window-open.html
3. Click the "open about:blank window" button. This creates and focuses Tab B.
4. Switch back to Tab A, and navigate it to https://www.chromium.org/
5. Open the Task Manager (Shift+Esc) and kill both "Incognito Tab" processes.
6. In Tab A, press the Back button in Tab A, and wait for it to load.
7. In Tab A, press the Forward button.

At this point Tab B is still a sad tab and isn't shown in the visible TaskManager -- but it shows up if you close and re-open the dialog.

My hunch is that we're keeping a process alive, because of the RenderFrameProxy that's created to replace Tab A's main frame in step 7.

Calling this a SiteIsolation bug based on the hunch that it's a zombielike RenderFrameProxy that's keeping this process alive.

Hmm, that looks like one part of this. I am repeatedly killing the resurrected processes and they come back after a while (hours or less). During a nine-hour work day I have to do this multiple times (just when I notice a slow-down or happen to look at Process Explorer for something else and notice much more Chrome processes than expected).

In M60, the above repro steps still work, except that the TaskManager part of the bug has been fixed (almost certainly because of Łukasz's change https://codereview.chromium.org/2857263003 ). Despite this, the leaked process is still there -- if you record the PID of Tab A in Step 6, it still exists in the Windows Task Manager.

Task Manager wise, cburn@ and I hope to implement a TaskManager feature where we'll surface unclaimed child pids as rows in the Task Manager -- maybe with lots of question marks, and (to avoid noise) probably only after they go unclaimed for 2 seconds or more. This is a case where just enumerating the RenderProcessHosts would have caught this maybe, and it provides a pretty strong motivation for implementing this feature.

Edit to #12: I said M60 but I was actually testing M61 canary. Actual behavior for M59 and M60 still needs to be determined.

Re @11: the bug as I understand it would have a necessary condition where two killed tabs are related -- specifically they must be in the same BrowsingInstance. When this happens, if you navigate one tab to the SiteInstance of the sad tab, and then navigate it again to a different site, we mistakenly keep the process alive for the use of the sad tab.

In M58, Ctrl+Click'ing a same-site link would have the effect of putting the new tab in the same SiteInstance/BrowsingInstance of the original tab, producing the necessary relationship to trigger these zombie sad tab processes. So, if many of your tabs were created via link Ctrl+Click operations (or similar "open in another tab" dispositions), then my explanation is hopefully consistent with the widespread zombification you're observing in your profile.

In M61 (possibly starting earlier) it seems like we've actually changed this behavior, and Ctrl+Click won't produce related tabs anymore -- but window.open still will.

Process allocation changes after ctrl-click probably come from r466187 (initially landed in 60.0.3077.0) and r466843 (initially landed in 60.0.3081.0).

1. Are those BrowsingInstance/SiteInstance maintained even after a relaunch (with "Continue where I left off" enabled)?

2. I think I neglected to mention one more thing. The resurrected tabs (tabs, not processes, read on. They remain sad tabs when you focus on them) sometimes join completely unrelated tabs (an intranet-based Jenkins tab is shared with GMail in the Chrome task manager, for example).
I guess that happens when the memory is low (or the process count is high) and Chrome decides to share processes between unrelated tabs.

Good questions; I think you're onto something. For your first question: no, BrowsingInstance relationships do not persist across restart. And two, if the tabs are totally unrelated, then it could easily be due to process reuse. 

Here's a way to force us into an that kind of scenario via an artificially low renderer process limit -- the tabs here will have different BrowsingInstances, but share a renderer process anyway because of the limit. 

My steps were:

#1. Launch chrome with three ordinary tabs and the renderer-process-limit set to two: chrome.exe --disable-extensions --renderer-process-limit=2 https://www.chromium.org https://csreis.github.io/tests https://www.facebook.com

#2. Open the TaskManager, you'll see that two of the tabs share a process. Pick one of the process-sharing tabs. Navigate it to a different site (I used news.google.com). Keep doing navigations until it switches to the other renderer process.

#3. Kill both processes.

#4. Reload the tab you were navigating.

#5. Note that back/forward/back/forward navigations just alternate between the 2 fixed process IDs shown in the task manager. These two child processes are being kept alive on behalf of the sad tabs.

These processes really ought to terminate themselves when they no longer contain any documents/workers. We need to keep the RPH around, but the renderer process should shutdown.

Having said that, I'll try doing a bisect to see if this is really a regression. It may always have worked this way.

(maybe a better #5 is: write down the PID, go back, write down the PID, then close this tab. Note that both the written-down PIDs remain alive in the OS task manager).

I've carved off https://bugs.chromium.org/p/chromium/issues/detail?id=736834 to capture an issue about tab discarding not seeming to actually freeing up memory in M58, in the case where process sharing occurs.

One more observation -
GMail had its process shared with some internal website. That internal website was held in a not-yet-alive (or discarded, not sure) tab. When I double clicked on the Chrome task manager entry for the internal website, it resurrected that tab up (I saw the tab reloads), removed the tab from the GMail process and created a new process for it.

Sorry, but this is so frustrating... I keep having to launch the Chrome task manager and kill those processes. They come back every few minutes and hog up my memory. :(
(Chrome 59)

Oh, it even happens with in-page navigation (hash changes). I basically go to a message in GMail and that is enough to resurrect zombies. :(
And since I always go to messages in GMail... Damn.

I'm not 100% sure I follow the discussion about resurrected tabs. In terms of "not yet loaded session restore tabs", and "discarded tabs", the logic for reviving them lives in the browser, and the only activation path is when the tab is brought to focus. To be clear, these tabs are reloading even though they never have focus?

In terms of renderer processes not cleaning themselves up despite no longer hosting anything: there are a couple related bugs that have been filed around this. I think this is a regression that's been around for a while, and we've seen it manifest in renderer processes whose contents have all been discarded.

For more info:

 https://crbug.com/736834 
 https://crbug.com/450876 

No, they are not reloading without focus, but a process that identifies itself in the Chrome task manager as containing those tabs is created without any interaction with those tabs. Sometimes (in low memory or high process count situations, I guess), it is not a whole process, but the records of those tabs are being added to existing processes. Double clicking on such cases in the Chrome task manager would focus on the tab and (re)load it.

Regarding "not cleaning themselves up" - that is not the right term. I kill them using the Chrome task manager - the processes are completely dead. After a while (or maybe following seemingly unrelated navigations), zombie processes are simply created for those tabs (or their zombie existence is shared with an existing process).

I think this behavior has started around Chrome 56 - 58 and possibly got worse (or I just noticed) around Chrome 58 or Chrome 59. I am fairly positive it did not reproduce around the Chrome 41 period like  issue 450876  states, so I do not think it is the same issue, but maybe Windows acquired its own version of the bug later than Chrome OS.

I too experience this issue. Also, it's been filed before for linux https://bugs.chromium.org/p/chromium/issues/detail?id=689281

I can easily have 30 - 40 zombie processes, using Chrome 60 as well.
Any conclusion?

On one of my machines (I think, perhaps I just did not notice on the other one), the Chrome task manager does not show the zombie processes. My machine was extra-slow and despite the Chrome task manager not showing anything fishy (only actually active processes were shown), I looked at Process Explorer and saw about ten zombie chrome.exe processes. :(

(Chrome 60)

I used the chrome.processes dev-channel-restricted Chrome extension API in order to create an extension that terminates those zombie processes.
Using chrome.processes.onCreated, I can see those unclaimed processes. Their task list always includes a single task -
{title: "Subframe: https://google.com/"}
chrome.processes.onExited is always triggered for them a few seconds after they are created. However, the process is kept alive in the Windows task manager (but not in the Chrome task manager).

What is this task?

I plan to create an extension with native messaging or something that kills those processes (exited, --type=renderer and still alive after a few seconds? Kill!) as an interim solution. I hope my machine will start responding once this is in place. I will post a link to it once (if) it is ready.

I was wrong, obviously. That subframe thingy is killed by Chrome after a few seconds.
But I still managed to create an extension (that requires a local server) that kills those extraneous processes.
I tested it on Windows. If it happens to work on other platforms, great.

Enjoy at your own risk -
https://github.com/phistuck/extraneous-process-detector-chrome-extension

This issue is still going on, even with the current canary (68.0.3438.0 (Official Build) canary (64-bit) (cohort: Clang-64)). I am sad.

The beauty of abundance. Chrome 66.

Could it really be that only a few users experience this?

Deleted: chrome-66-many-processes.png 87.7 KB

	chrome-66-many-processes.png 87.7 KB View Download

We can now easily reproduce this bug, and have some ideas about what is causing it. We're aiming to have it fixed in M69. Closing this.

This issue must have a separate root cause from issue 840409, because SpareRenderProcessHostManager wasn't used on desktop OSes until M67.  Let me un-dupe.

:(
This is not over yet...

Google Chrome	69.0.3457.2 (Official Build) canary (64-bit) (cohort: Clang-64)

Sorry for the Samara (from "The Ring") scratching ;) I was too lazy to use a proper tool.

Deleted: unknown-child-chrome-processes-redux.png 90.3 KB

	unknown-child-chrome-processes-redux.png 90.3 KB View Download