Ensure we don't have zombie child processes that get started but never get a chance to connect to t…

Ensure we don't have zombie child processes that get started but never get a chance to connect to the browser process. Since they never connected, they will never have an OnChannelError and so they don't get destroyed.

This was causing the sharding_supervisor script to hang on Linux since there were child processes that didn't exit. It looks like there are race conditions in some tests where child processes start but the browser closes before they can connect. Probably we only see this on Linux because it's faster than other platforms or the shutdown timing is different.

BUG=140054
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=150278

[Avi (use Gerrit), 2012-08-07 04:50:51]

http://codereview.chromium.org/10855013/diff/3001/content/common/child_thread.cc
File content/common/child_thread.cc (right):

http://codereview.chromium.org/10855013/diff/3001/content/common/child_thread...
content/common/child_thread.cc:42: // terminates child processes automatically.
For unsanboxed processes (i.e.
s/terminates/terminate/ to match quantity.
s/unsanboxed/unsandboxed/ typo fix.

http://codereview.chromium.org/10855013/diff/3001/content/common/child_thread...
content/common/child_thread.cc:79:
base::TimeDelta::FromSeconds(kSuicideTimeoutS));
This change from immediate exit to delayed suicide is not explained.

[jam, 2012-08-07 04:54:27]

http://codereview.chromium.org/10855013/diff/3001/content/common/child_thread.cc
File content/common/child_thread.cc (right):

http://codereview.chromium.org/10855013/diff/3001/content/common/child_thread...
content/common/child_thread.cc:42: // terminates child processes automatically.
For unsanboxed processes (i.e.
On 2012/08/07 04:50:51, Avi wrote:
> s/terminates/terminate/ to match quantity.

updated objects to object since there's only one

> s/unsanboxed/unsandboxed/ typo fix.

Done

http://codereview.chromium.org/10855013/diff/3001/content/common/child_thread...
content/common/child_thread.cc:79:
base::TimeDelta::FromSeconds(kSuicideTimeoutS));
On 2012/08/07 04:50:51, Avi wrote:
> This change from immediate exit to delayed suicide is not explained.

On second thoughts, I'll remove that from this change.

[Avi (use Gerrit), 2012-08-07 04:57:48]

lgtm

http://codereview.chromium.org/10855013/diff/6003/content/common/child_thread.cc
File content/common/child_thread.cc (right):

http://codereview.chromium.org/10855013/diff/6003/content/common/child_thread...
content/common/child_thread.cc:43: // plugins), PluginThread has
EnsureTerminateMessageFilter.
EnsureTerminateMessageFilter? So we've seen this before? :) Every time we fix an
issue with plugins we should check to see if the misbehavedness of them extends
to a lesser extent to other things.

[jam, 2012-08-07 05:07:46]

http://codereview.chromium.org/10855013/diff/6003/content/common/child_thread.cc
File content/common/child_thread.cc (right):

http://codereview.chromium.org/10855013/diff/6003/content/common/child_thread...
content/common/child_thread.cc:43: // plugins), PluginThread has
EnsureTerminateMessageFilter.
On 2012/08/07 04:57:48, Avi wrote:
> EnsureTerminateMessageFilter? So we've seen this before? :) Every time we fix
an
> issue with plugins we should check to see if the misbehavedness of them
extends
> to a lesser extent to other things.

What happened is plugins got fixed for all platforms initially (since they're
not sandboxed and so the sandbox' job object doesn't quit them). workers/utility
processes quit automatically on windows because of the job object. but on linux,
that isn't the case, so this filter got added only for renderers. i saw this
issue for workers as well, so i made it happen for all child processes on linux
in another change last week.