Make Crashpad start asynchronous, and move back to chrome_elf

components/crash/content/app/crashpad_win.cc

Index: components/crash/content/app/crashpad_win.cc
diff --git a/components/crash/content/app/crashpad_win.cc b/components/crash/content/app/crashpad_win.cc
index a22af313a622b6332a8630b09e9ff74d97ed2d1d..6636fa2cd6e51adb54d06f4fc3c3d55c747f232f 100644
--- a/components/crash/content/app/crashpad_win.cc
+++ b/components/crash/content/app/crashpad_win.cc
@@ -120,7 +120,7 @@ base::FilePath PlatformCrashpadInitialization(bool initial_client,
 
     g_crashpad_client.Get().StartHandler(
         exe_file, database_path, metrics_path, url, process_annotations,
-        arguments, false, false);
+        arguments, false, true);
 
     // If we're the browser, push the pipe name into the environment so child
     // processes can connect to it. If we inherited another crashpad_handler's
@@ -190,6 +190,13 @@ MSVC_ENABLE_OPTIMIZE()
 }  // namespace
 
 }  // namespace internal
+
+void BlockUntilHandlerStarted() {
+  if (!internal::g_crashpad_client.Get().WaitForHandlerStart()) {

[Mark Mentovai, 2016/11/04 21:47:56]

This isn’t valid unless StartHandler() returned true. There’s even a DCHECK()
that this will trip over.

[scottmg, 2016/11/04 22:13:41]

Ah good point, I was only considering the async part. I'm going to burn things
down rather than try to set bools and continue if the _synchronous_ part of
StartHandler() fails. That means that a simple call to CreateThread() very early
in the process lifetime failed, implying that the process is totally screwed, so
continuing probably isn't worthwhile. So I LOG(FATAL)d above at StartHandler(),
and noted the dependency in comments.

+    LOG(ERROR) << "Crashpad handler failed to start, crash reporting disabled";
+  }
+}
+
 }  // namespace crash_reporter
 
 extern "C" {