Breakpad coverage for chrome_elf start up

chrome_elf/chrome_elf_main.cc

Index: chrome_elf/chrome_elf_main.cc
diff --git a/chrome_elf/chrome_elf_main.cc b/chrome_elf/chrome_elf_main.cc
index 772c906f1d4e66d07739f797afb7fc867390ba4d..6d9e42f715f3b501dcf17e401e1541d8efafa0e9 100644
--- a/chrome_elf/chrome_elf_main.cc
+++ b/chrome_elf/chrome_elf_main.cc
@@ -7,6 +7,7 @@
 #include "chrome_elf/chrome_elf_main.h"
 
 #include "chrome_elf/blacklist/blacklist.h"
+#include "chrome_elf/breakpad.h"
 #include "chrome_elf/ntdll_cache.h"
 
 void SignalChromeElf() {
@@ -15,11 +16,23 @@ void SignalChromeElf() {
 
 BOOL APIENTRY DllMain(HMODULE module, DWORD reason, LPVOID reserved) {
   if (reason == DLL_PROCESS_ATTACH) {
-    InitCache();
-    blacklist::Initialize(false);  // Don't force, abort if beacon is present.
+    // TODO (caitkp): Do we need this? If so, how do we make it play nice with

[Sigurður Ásgeirsson, 2014/02/05 13:58:33]

A single function cannot have objects that require unwinding and __try/__except
handlers. If you need this, you need to move the __try/__except into another
function - a file static or anonymous namespace function is fine.

[Cait (Slow), 2014/02/07 15:32:02]

Not needed anymore as our breakpad client no longer uses LazyInstance

+    // the try catch?
+    //base::AtExitManager exit_manager;
+    InitializeCrashReporting();
+
+    __try {
+      InitCache();
+      blacklist::Initialize(false);  // Don't force, abort if beacon is present.
+    } __except(GenerateCrashDump(GetExceptionInformation())) {
+    }
 
     // TODO(csharp): Move additions to the DLL blacklist to a sane place.
     // blacklist::AddDllToBlacklist(L"foo.dll");
+
+    // TODO(caitkp): We should really de-initialize our breakpad client here, to

[Sigurður Ásgeirsson, 2014/02/05 13:58:33]

I don't know that this is true.
As-is, you're also getting breakpad coverage for the initialization of all of
chrome.exe's dependent DLLs.

[Cait (Slow), 2014/02/07 15:32:02]

Did some very unscientific research here, and it seems that as long as everyone
is using the same pipe, chrome's breakpad client will just replace ours when it
starts. In fact, if not shut down properly on the previous run, Chrome currently
starts it's breakpad client twice (once on initial launch, once on relaunch), so
I think Siggi is correct that no clean-up is needed here.

Unfortunately, we don't get the coverage of other dependent DLLs, unless we wrap
them in try/excepts as we have done for elf.

+    // ensure that we don't block Chrome's when it tries to connect in win_main.
+
   }
 
   return TRUE;