Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

See bug for details of regression.

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

TBR=mark@chromium.org, thestig@chromium.org, grt@chromium.org
BUG=700371
Review-Url: https://codereview.chromium.org/2743923003
Cr-Commit-Position: refs/heads/master@{#456221}
Committed: https://chromium.googlesource.com/chromium/src/+/616b30a936244b12170072859a0ca988459a6a1b

[scottmg, 2017-03-10 20:02:15]

Description was changed from

==========
Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

BUG=700731
==========

to

==========
Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

BUG=700731
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
==========

[scottmg, 2017-03-10 20:04:11]

The CQ bit was checked by scottmg@chromium.org to run a CQ dry run

[scottmg, 2017-03-10 20:04:52]

Description was changed from

==========
Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

BUG=700731
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
==========

to

==========
Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

BUG=700731
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
==========

[scottmg, 2017-03-10 20:04:52]

scottmg@chromium.org changed reviewers:
+ mark@chromium.org, thestig@chromium.org

[commit-bot: I haz the power, 2017-03-10 20:04:56]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[scottmg, 2017-03-10 20:05:37]

Description was changed from

==========
Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

BUG=700731
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
==========

to

==========
Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

See bug for details of regression.

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

BUG=700731
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
==========

[commit-bot: I haz the power, 2017-03-10 20:23:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-10 20:23:51]

Dry run: Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[scottmg, 2017-03-10 20:36:57]

The CQ bit was checked by scottmg@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-10 20:37:28]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[scottmg, 2017-03-10 20:40:19]

The CQ bit was checked by scottmg@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-10 20:40:53]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[scottmg, 2017-03-10 20:45:34]

scottmg@chromium.org changed reviewers:
+ grt@chromium.org

[scottmg, 2017-03-10 20:58:45]

Description was changed from

==========
Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

See bug for details of regression.

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

BUG=700731
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
==========

to

==========
Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

See bug for details of regression.

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

TBR=mark@chromium.org, thestig@chromium.org, grt@chromium.org
BUG=700731
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
==========

[Mark Mentovai, 2017-03-10 21:15:28]

LGTM otherwise

https://codereview.chromium.org/2743923003/diff/60001/chrome/app/chrome_exe_m...
File chrome/app/chrome_exe_main_win.cc (right):

https://codereview.chromium.org/2743923003/diff/60001/chrome/app/chrome_exe_m...
chrome/app/chrome_exe_main_win.cc:1: // Copyright (c) 2011 The Chromium Authors.
All rights reserved.
CL description:

> BUG=700731

404, check that.

[scottmg, 2017-03-10 21:19:32]

Description was changed from

==========
Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

See bug for details of regression.

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

TBR=mark@chromium.org, thestig@chromium.org, grt@chromium.org
BUG=700731
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
==========

to

==========
Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

See bug for details of regression.

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

TBR=mark@chromium.org, thestig@chromium.org, grt@chromium.org
BUG=700371
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
==========

[scottmg, 2017-03-10 21:19:46]

On 2017/03/10 21:15:28, Mark Mentovai wrote:
> LGTM otherwise
> 
>
https://codereview.chromium.org/2743923003/diff/60001/chrome/app/chrome_exe_m...
> File chrome/app/chrome_exe_main_win.cc (right):
> 
>
https://codereview.chromium.org/2743923003/diff/60001/chrome/app/chrome_exe_m...
> chrome/app/chrome_exe_main_win.cc:1: // Copyright (c) 2011 The Chromium
Authors.
> All rights reserved.
> CL description:
> 
> > BUG=700731
> 
> 404, check that.

oops, thanks. should be 700371.

[scottmg, 2017-03-10 22:01:55]

The CQ bit was unchecked by scottmg@chromium.org

[scottmg, 2017-03-10 22:01:58]

The CQ bit was checked by scottmg@chromium.org

[commit-bot: I haz the power, 2017-03-10 22:02:30]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-10 23:48:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-10 23:48:52]

Try jobs failed on following builders:
  win10_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win10_chromium_x6...)

[scottmg, 2017-03-10 23:51:43]

Description was changed from

==========
Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

See bug for details of regression.

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

TBR=mark@chromium.org, thestig@chromium.org, grt@chromium.org
BUG=700371
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
==========

to

==========
Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

See bug for details of regression.

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

TBR=mark@chromium.org, thestig@chromium.org, grt@chromium.org
BUG=700371
==========

[scottmg, 2017-03-10 23:52:21]

removed win10 bot from "extra cq". it passed in ps#3, but is having trouble.
i'll file a bug to get those looked at.

[scottmg, 2017-03-10 23:52:26]

The CQ bit was checked by scottmg@chromium.org

[commit-bot: I haz the power, 2017-03-10 23:52:49]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-10 23:58:13]

CQ is committing da patch.

Bot data: {"patchset_id": 60001, "attempt_start_ts": 1489189946703550,
"parent_rev": "61e9098658727a38b2043767a917d8f5c637130a", "commit_rev":
"616b30a936244b12170072859a0ca988459a6a1b"}

[commit-bot: I haz the power, 2017-03-10 23:58:57]

Description was changed from

==========
Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

See bug for details of regression.

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

TBR=mark@chromium.org, thestig@chromium.org, grt@chromium.org
BUG=700371
==========

to

==========
Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

See bug for details of regression.

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

TBR=mark@chromium.org, thestig@chromium.org, grt@chromium.org
BUG=700371

Review-Url: https://codereview.chromium.org/2743923003
Cr-Commit-Position: refs/heads/master@{#456221}
Committed:
https://chromium.googlesource.com/chromium/src/+/616b30a936244b12170072859a0c...
==========

[commit-bot: I haz the power, 2017-03-10 23:58:58]

Committed patchset #4 (id:60001) as
https://chromium.googlesource.com/chromium/src/+/616b30a936244b12170072859a0c...