Switch chrome_elf exception handling from breakpad to crashpad.

Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest. This is via the exe name check.

2. chrome.exe:- Removing crashpad exception registration. Also we need to retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching on the exe and disallow the call. This
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

4. Added a function RegisterCrashKeysForDebugging to the ChromeCrashReporterClient class on Windows
   to register crash keys. This is currently invoked from chrome_elf for debugging purposes.

5. Changed the browser lib target to depend on chrome_elf:blacklist instead of chrome_elf. This prevents chrome_elf
   from being implicitly loaded in processes other than chrome.exe

BUG=604923, crashpad:106, 568664
TBR=robertshield

Committed: https://crrev.com/34831427124fef3015106cfe6e94d35f3aa9e4f6
Cr-Commit-Position: refs/heads/master@{#403048}

[ananta, 2016-06-22 03:32:49]

ananta@chromium.org changed reviewers:
+ robertshield@chromium.org, scottmg@chromium.org

[robertshield, 2016-06-22 04:09:32]

Lg overall, couple of comment requests and there's a dependency failure on one
of the bots here:
https://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds...

https://codereview.chromium.org/2088133002/diff/20001/chrome/browser/crash_up...
File chrome/browser/crash_upload_list/crash_upload_list_crashpad.cc (right):

https://codereview.chromium.org/2088133002/diff/20001/chrome/browser/crash_up...
chrome/browser/crash_upload_list/crash_upload_list_crashpad.cc:25: HMODULE
exe_module = GetModuleHandle(L"chrome_elf.dll");
exe_module should be renamed to elf_module and accompanied by a comment
indicating the chrome_elf.dll is where early process initialization happens.

https://codereview.chromium.org/2088133002/diff/20001/chrome_elf/chrome_elf_m...
File chrome_elf/chrome_elf_main.cc (right):

https://codereview.chromium.org/2088133002/diff/20001/chrome_elf/chrome_elf_m...
chrome_elf/chrome_elf_main.cc:26: // This helper is looked up in the browser to
retrieve the crash reports. See
perhaps s/looked up in the browser/looked up by code in chrome.dll/

[ananta, 2016-06-22 19:30:33]

https://codereview.chromium.org/2088133002/diff/20001/chrome/browser/crash_up...
File chrome/browser/crash_upload_list/crash_upload_list_crashpad.cc (right):

https://codereview.chromium.org/2088133002/diff/20001/chrome/browser/crash_up...
chrome/browser/crash_upload_list/crash_upload_list_crashpad.cc:25: HMODULE
exe_module = GetModuleHandle(L"chrome_elf.dll");
On 2016/06/22 04:09:32, robertshield wrote:
> exe_module should be renamed to elf_module and accompanied by a comment
> indicating the chrome_elf.dll is where early process initialization happens.

Added this comment.
The crash reporting is handled by chrome_elf.dll which loads early in the chrome
process.

https://codereview.chromium.org/2088133002/diff/20001/chrome_elf/chrome_elf_m...
File chrome_elf/chrome_elf_main.cc (right):

https://codereview.chromium.org/2088133002/diff/20001/chrome_elf/chrome_elf_m...
chrome_elf/chrome_elf_main.cc:26: // This helper is looked up in the browser to
retrieve the crash reports. See
On 2016/06/22 04:09:32, robertshield wrote:
> perhaps s/looked up in the browser/looked up by code in chrome.dll/

Done.

[scottmg, 2016-06-22 19:38:07]

Exciting!

Does it actually work? :)

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/BUILD.gn
File chrome_elf/BUILD.gn (right):

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/BUILD.gn#new...
chrome_elf/BUILD.gn:119: "crashpad_helper.cc",
I don't think this should be in both blacklist and in chrome_elf as chrome_elf
depends on this.

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/chrome_elf.gyp
File chrome_elf/chrome_elf.gyp (right):

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/chrome_elf.g...
chrome_elf/chrome_elf.gyp:40: 'crashpad_helper.cc',
Same for gyp.

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/chrome_elf_m...
File chrome_elf/chrome_elf_main.cc (right):

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/chrome_elf_m...
chrome_elf/chrome_elf_main.cc:17:
base::LazyInstance<std::vector<crash_reporter::Report>>::Leaky
Add \n here, or remove after definition.

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/chrome_elf_m...
chrome_elf/chrome_elf_main.cc:41:
ChromeCrashReporterClient::InitializeCrashReportingForProcess();
It looks like InitializeCrashReportingForProcess redoes the process type check.
Could this go before that?

Otherwise, should it use g_process_type?

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/crashpad_hel...
File chrome_elf/crashpad_helper.cc (right):

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/crashpad_hel...
chrome_elf/crashpad_helper.cc:9: crashpad::CrashpadClient::DumpWithoutCrash(
This is going to generate two crash dumps now, right? e.g. in the __try/__except
around BlNtMapViewOfSectionImpl we'd dump once, and then dump again when we get
to the UnhandledExceptionFilter? (maybe this is more a question for Robert than
Ananta)

[robertshield, 2016-06-22 19:47:45]

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/crashpad_hel...
File chrome_elf/crashpad_helper.cc (right):

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/crashpad_hel...
chrome_elf/crashpad_helper.cc:9: crashpad::CrashpadClient::DumpWithoutCrash(
On 2016/06/22 19:38:07, scottmg wrote:
> This is going to generate two crash dumps now, right? e.g. in the
__try/__except
> around BlNtMapViewOfSectionImpl we'd dump once, and then dump again when we
get
> to the UnhandledExceptionFilter? (maybe this is more a question for Robert
than
> Ananta)

Sometimes, yes. In practice quite often this is hit by e.g. foo.dll loading
bar.dll loading baz.dll with an exception somewhere down the chain that is
caught and handled by something (not us) further up like foo.dll or bar.dll.

In this case the exception doesn't hit the unhandled exception handler, which is
why we also catch it in BlNtMapViewOfSectionImpl .

[ananta, 2016-06-22 21:08:20]

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/BUILD.gn
File chrome_elf/BUILD.gn (right):

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/BUILD.gn#new...
chrome_elf/BUILD.gn:119: "crashpad_helper.cc",
On 2016/06/22 19:38:07, scottmg wrote:
> I don't think this should be in both blacklist and in chrome_elf as chrome_elf
> depends on this.

Yeah. Moved the files to the blacklist folder.

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/chrome_elf_m...
File chrome_elf/chrome_elf_main.cc (right):

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/chrome_elf_m...
chrome_elf/chrome_elf_main.cc:17:
base::LazyInstance<std::vector<crash_reporter::Report>>::Leaky
On 2016/06/22 19:38:07, scottmg wrote:
> Add \n here, or remove after definition.

Done.

https://codereview.chromium.org/2088133002/diff/40001/chrome_elf/chrome_elf_m...
chrome_elf/chrome_elf_main.cc:41:
ChromeCrashReporterClient::InitializeCrashReportingForProcess();
On 2016/06/22 19:38:07, scottmg wrote:
> It looks like InitializeCrashReportingForProcess redoes the process type
check.
> Could this go before that?
> 
> Otherwise, should it use g_process_type?

Switched the order. g_process_type identifies a process as a browser or non
browser based on whether it is sandboxed

[scottmg, 2016-06-22 21:18:24]

lgtm

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

https://codereview.chromium.org/2088133002/diff/60001/chrome/app/chrome_exe_m...
chrome/app/chrome_exe_main_win.cc:26: #include
"chrome/app/chrome_crash_reporter_client_win.h"
Remove some includes here?

https://codereview.chromium.org/2088133002/diff/60001/chrome/app/chrome_exe_m...
chrome/app/chrome_exe_main_win.cc:34: #include
"components/crash/content/app/crash_reporter_client.h"
And here.

https://codereview.chromium.org/2088133002/diff/60001/chrome/browser/crash_up...
File chrome/browser/crash_upload_list/crash_upload_list_crashpad.cc (right):

https://codereview.chromium.org/2088133002/diff/60001/chrome/browser/crash_up...
chrome/browser/crash_upload_list/crash_upload_list_crashpad.cc:12: #include
"chrome/common/chrome_constants.h"
This can be removed I think. (Is there a constant for "chrome_elf.dll"
anywhere?)

[ananta, 2016-06-22 21:25:08]

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

https://codereview.chromium.org/2088133002/diff/60001/chrome/app/chrome_exe_m...
chrome/app/chrome_exe_main_win.cc:26: #include
"chrome/app/chrome_crash_reporter_client_win.h"
On 2016/06/22 21:18:23, scottmg wrote:
> Remove some includes here?

Done.

https://codereview.chromium.org/2088133002/diff/60001/chrome/app/chrome_exe_m...
chrome/app/chrome_exe_main_win.cc:34: #include
"components/crash/content/app/crash_reporter_client.h"
On 2016/06/22 21:18:24, scottmg wrote:
> And here.

Done.

https://codereview.chromium.org/2088133002/diff/60001/chrome/browser/crash_up...
File chrome/browser/crash_upload_list/crash_upload_list_crashpad.cc (right):

https://codereview.chromium.org/2088133002/diff/60001/chrome/browser/crash_up...
chrome/browser/crash_upload_list/crash_upload_list_crashpad.cc:12: #include
"chrome/common/chrome_constants.h"
On 2016/06/22 21:18:24, scottmg wrote:
> This can be removed I think. (Is there a constant for "chrome_elf.dll"
> anywhere?)

Thanks. done. There is no constant for chrome_elf.dll. Unsure of a good place to
define it in. Maybe install_static. But again we need to remove the dups in that
library and define them in a common place.

[ananta, 2016-06-22 21:29:29]

ananta@chromium.org changed reviewers:
+ sky@chromium.org

[ananta, 2016-06-22 21:29:30]

+sky for chrome owners stamp

[sky, 2016-06-22 23:04:59]

LGTM

[ananta, 2016-06-24 08:45:10]

Description was changed from

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

BUG=604923
==========

to

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

BUG=604923
==========

[ananta, 2016-06-24 08:47:08]

Description was changed from

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

BUG=604923
==========

to

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in
chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

BUG=604923
==========

[ananta, 2016-06-25 00:52:25]

Description was changed from

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in
chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

BUG=604923
==========

to

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in
chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest.
This is via the exe name check.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

4. Added a function RegisterCrashKeysForDebugging to the
ChromeCrashReporterClient class on Windows
   to register crash keys. This is currently invoked from chrome_elf for
debugging purposes.

5. Changed the browser lib target to depend on chrome_elf:blacklist instead of
chrome_elf. This prevents chrome_elf
   from being implicitly loaded in processes other than chrome.exe

BUG=604923
==========

[ananta, 2016-06-25 00:52:26]

Description was changed from

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in
chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

BUG=604923
==========

to

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in
chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest.
This is via the exe name check.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

4. Added a function RegisterCrashKeysForDebugging to the
ChromeCrashReporterClient class on Windows
   to register crash keys. This is currently invoked from chrome_elf for
debugging purposes.

5. Changed the browser lib target to depend on chrome_elf:blacklist instead of
chrome_elf. This prevents chrome_elf
   from being implicitly loaded in processes other than chrome.exe

BUG=604923
==========

[ananta, 2016-06-25 02:02:14]

Please take a peek at the updated patch guys. crashpad is now functional in
chrome and we can see crashes in the crashpad folder in the profile directory. I
have updated the patchset description to describe the overall changes.

Thanks

[scottmg, 2016-06-27 19:37:46]

(Still trying to make progress on the need to register keys.)

https://codereview.chromium.org/2088133002/diff/180001/chrome/app/chrome_cras...
File chrome/app/chrome_crash_reporter_client_win.cc (right):

https://codereview.chromium.org/2088133002/diff/180001/chrome/app/chrome_cras...
chrome/app/chrome_crash_reporter_client_win.cc:72: // Crash keys should be
registered only once for the duration of the
Why is this getting called multiple times now?

https://codereview.chromium.org/2088133002/diff/180001/chrome/common/child_pr...
File chrome/common/child_process_logging_win.cc (right):

https://codereview.chromium.org/2088133002/diff/180001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:62: // Please note if we are using
CrashPad via chrome_elf then we need to call
nit; CrashPad -> Crashpad

https://codereview.chromium.org/2088133002/diff/180001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:82: if (client_info)
This should be out of the if/else I think?

https://codereview.chromium.org/2088133002/diff/180001/chrome_elf/chrome_elf_...
File chrome_elf/chrome_elf_main.cc (right):

https://codereview.chromium.org/2088133002/diff/180001/chrome_elf/chrome_elf_...
chrome_elf/chrome_elf_main.cc:52: // chrome_elf loads early in the process and
initializes CrashPad. That in turn
CrashPad -> Crashpad

https://codereview.chromium.org/2088133002/diff/180001/chrome_elf/chrome_elf_...
chrome_elf/chrome_elf_main.cc:70: // Don't set the exception filter. Please see
above for comments.
Add ",crashpad:106" to the BUG= line, since you fixed this (awesome!
https://bugs.chromium.org/p/crashpad/issues/detail?id=106)

[ananta, 2016-06-27 19:55:28]

Description was changed from

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in
chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest.
This is via the exe name check.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

4. Added a function RegisterCrashKeysForDebugging to the
ChromeCrashReporterClient class on Windows
   to register crash keys. This is currently invoked from chrome_elf for
debugging purposes.

5. Changed the browser lib target to depend on chrome_elf:blacklist instead of
chrome_elf. This prevents chrome_elf
   from being implicitly loaded in processes other than chrome.exe

BUG=604923
==========

to

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in
chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest.
This is via the exe name check.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

4. Added a function RegisterCrashKeysForDebugging to the
ChromeCrashReporterClient class on Windows
   to register crash keys. This is currently invoked from chrome_elf for
debugging purposes.

5. Changed the browser lib target to depend on chrome_elf:blacklist instead of
chrome_elf. This prevents chrome_elf
   from being implicitly loaded in processes other than chrome.exe

BUG=604923,crashpad:106
==========

[ananta, 2016-06-27 20:00:27]

https://codereview.chromium.org/2088133002/diff/180001/chrome/app/chrome_cras...
File chrome/app/chrome_crash_reporter_client_win.cc (right):

https://codereview.chromium.org/2088133002/diff/180001/chrome/app/chrome_cras...
chrome/app/chrome_crash_reporter_client_win.cc:72: // Crash keys should be
registered only once for the duration of the
On 2016/06/27 19:37:46, scottmg wrote:
> Why is this getting called multiple times now?

Can get called from child_process_logging_win.cc which is part of this patchset.
Don't want to register keys twice as that fires DCHECK's

https://codereview.chromium.org/2088133002/diff/180001/chrome/common/child_pr...
File chrome/common/child_process_logging_win.cc (right):

https://codereview.chromium.org/2088133002/diff/180001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:62: // Please note if we are using
CrashPad via chrome_elf then we need to call
On 2016/06/27 19:37:46, scottmg wrote:
> nit; CrashPad -> Crashpad

Done.

https://codereview.chromium.org/2088133002/diff/180001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:82: if (client_info)
On 2016/06/27 19:37:46, scottmg wrote:
> This should be out of the if/else I think?

No. If exception handling is being done by chrome_elf then that function
internally calls crash_keys::SetMetricsClientIdFromGUID

https://codereview.chromium.org/2088133002/diff/180001/chrome_elf/chrome_elf_...
File chrome_elf/chrome_elf_main.cc (right):

https://codereview.chromium.org/2088133002/diff/180001/chrome_elf/chrome_elf_...
chrome_elf/chrome_elf_main.cc:52: // chrome_elf loads early in the process and
initializes CrashPad. That in turn
On 2016/06/27 19:37:46, scottmg wrote:
> CrashPad -> Crashpad

Done.

https://codereview.chromium.org/2088133002/diff/180001/chrome_elf/chrome_elf_...
chrome_elf/chrome_elf_main.cc:70: // Don't set the exception filter. Please see
above for comments.
On 2016/06/27 19:37:46, scottmg wrote:
> Add ",crashpad:106" to the BUG= line, since you fixed this (awesome!
> https://bugs.chromium.org/p/crashpad/issues/detail?id=106)

Done.

[scottmg, 2016-06-27 20:09:24]

https://codereview.chromium.org/2088133002/diff/180001/chrome/common/child_pr...
File chrome/common/child_process_logging_win.cc (right):

https://codereview.chromium.org/2088133002/diff/180001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:81:
crash_keys::RegisterChromeCrashKeys();
I'm confused now, when is the non-elf path going to be taken (since this is
chrome-only and _win only)?

https://codereview.chromium.org/2088133002/diff/180001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:82: if (client_info)
On 2016/06/27 20:00:26, ananta wrote:
> On 2016/06/27 19:37:46, scottmg wrote:
> > This should be out of the if/else I think?
> 
> No. If exception handling is being done by chrome_elf then that function
> internally calls crash_keys::SetMetricsClientIdFromGUID

Ah, OK. Let's call RegisterCrashKeysImpl something else then, otherwise we might
forget to keep that part of it once we no longer need to pre-register crash
keys. "RegisterCrashKeysAndSetMetricsId" or something.

[ananta, 2016-06-27 20:36:06]

https://codereview.chromium.org/2088133002/diff/180001/chrome/common/child_pr...
File chrome/common/child_process_logging_win.cc (right):

https://codereview.chromium.org/2088133002/diff/180001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:82: if (client_info)
On 2016/06/27 20:09:24, scottmg wrote:
> On 2016/06/27 20:00:26, ananta wrote:
> > On 2016/06/27 19:37:46, scottmg wrote:
> > > This should be out of the if/else I think?
> > 
> > No. If exception handling is being done by chrome_elf then that function
> > internally calls crash_keys::SetMetricsClientIdFromGUID
> 
> Ah, OK. Let's call RegisterCrashKeysImpl something else then, otherwise we
might
> forget to keep that part of it once we no longer need to pre-register crash
> keys. "RegisterCrashKeysAndSetMetricsId" or something.

Done.

[scottmg, 2016-06-27 20:42:49]

https://codereview.chromium.org/2088133002/diff/220001/chrome/browser/crash_u...
File chrome/browser/crash_upload_list/crash_upload_list_crashpad.cc (right):

https://codereview.chromium.org/2088133002/diff/220001/chrome/browser/crash_u...
chrome/browser/crash_upload_list/crash_upload_list_crashpad.cc:26: HMODULE
elf_module = GetModuleHandle(L"chrome_elf.dll");
Since there's a bunch of places we need this string now, please add
kChromeElfDllName to chrome_constants.h.

https://codereview.chromium.org/2088133002/diff/220001/chrome/common/child_pr...
File chrome/common/child_process_logging_win.cc (right):

https://codereview.chromium.org/2088133002/diff/220001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:33: HMODULE elf_module =
GetModuleHandle(L"chrome_elf.dll");
Here,

https://codereview.chromium.org/2088133002/diff/220001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:46: HMODULE elf_module =
GetModuleHandle(L"chrome_elf.dll");
here,

https://codereview.chromium.org/2088133002/diff/220001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:72: HMODULE elf_module =
GetModuleHandle(L"chrome_elf.dll");
and here too.

https://codereview.chromium.org/2088133002/diff/220001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:81: } else {
When is this branch taken?

https://codereview.chromium.org/2088133002/diff/220001/chrome_elf/chrome_elf_...
File chrome_elf/chrome_elf_main.cc (right):

https://codereview.chromium.org/2088133002/diff/220001/chrome_elf/chrome_elf_...
chrome_elf/chrome_elf_main.cc:106: // Remove this when the change to not require
crash key registration lands.
Move this comment down to the Register part in the body, as we'll need to keep
this function to set the MetricsId.

[ananta, 2016-06-27 22:52:23]

https://codereview.chromium.org/2088133002/diff/220001/chrome/browser/crash_u...
File chrome/browser/crash_upload_list/crash_upload_list_crashpad.cc (right):

https://codereview.chromium.org/2088133002/diff/220001/chrome/browser/crash_u...
chrome/browser/crash_upload_list/crash_upload_list_crashpad.cc:26: HMODULE
elf_module = GetModuleHandle(L"chrome_elf.dll");
On 2016/06/27 20:42:48, scottmg wrote:
> Since there's a bunch of places we need this string now, please add
> kChromeElfDllName to chrome_constants.h.

Done.

https://codereview.chromium.org/2088133002/diff/220001/chrome/common/child_pr...
File chrome/common/child_process_logging_win.cc (right):

https://codereview.chromium.org/2088133002/diff/220001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:33: HMODULE elf_module =
GetModuleHandle(L"chrome_elf.dll");
On 2016/06/27 20:42:49, scottmg wrote:
> Here,

Done.

https://codereview.chromium.org/2088133002/diff/220001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:46: HMODULE elf_module =
GetModuleHandle(L"chrome_elf.dll");
On 2016/06/27 20:42:48, scottmg wrote:
> here,

Done.

https://codereview.chromium.org/2088133002/diff/220001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:72: HMODULE elf_module =
GetModuleHandle(L"chrome_elf.dll");
On 2016/06/27 20:42:49, scottmg wrote:
> and here too.

Done.

https://codereview.chromium.org/2088133002/diff/220001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:81: } else {
On 2016/06/27 20:42:48, scottmg wrote:
> When is this branch taken?

When we are in tests code like browser_tests or interactive_ui_tests

https://codereview.chromium.org/2088133002/diff/220001/chrome_elf/chrome_elf_...
File chrome_elf/chrome_elf_main.cc (right):

https://codereview.chromium.org/2088133002/diff/220001/chrome_elf/chrome_elf_...
chrome_elf/chrome_elf_main.cc:106: // Remove this when the change to not require
crash key registration lands.
On 2016/06/27 20:42:49, scottmg wrote:
> Move this comment down to the Register part in the body, as we'll need to keep
> this function to set the MetricsId.

Done.

[scottmg, 2016-06-27 23:35:55]

lgtm

https://codereview.chromium.org/2088133002/diff/260001/chrome/common/chrome_c...
File chrome/common/chrome_constants.cc (left):

https://codereview.chromium.org/2088133002/diff/260001/chrome/common/chrome_c...
chrome/common/chrome_constants.cc:202: #if defined(OS_WIN)
Thanks for cleaning this up, but please put it in a separate CL (there's a fair
chance this one might get reverted :)

[ananta, 2016-06-27 23:48:42]

+sky. Please peek at the chrome changes one more time

[sky, 2016-06-28 02:40:45]

LGTM assuming the following is ok.

I do have one question though. Lets say there is a bug in how this is setup, how
would we know we aren't receiving crash reports?

https://codereview.chromium.org/2088133002/diff/260001/chrome/common/child_pr...
File chrome/common/child_process_logging_win.cc (right):

https://codereview.chromium.org/2088133002/diff/260001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:77: set_metrics_id_fn(client_info ?
client_info->client_id.c_str() : nullptr);
Does SetMetricsClientId make a copy of the char*?

[ananta, 2016-06-28 03:15:44]

Currently it is all manual testing, and some individual unittests for portions
of the code being run here.

We would know quickly in Canary whether reports are coming in or not.

https://codereview.chromium.org/2088133002/diff/260001/chrome/common/child_pr...
File chrome/common/child_process_logging_win.cc (right):

https://codereview.chromium.org/2088133002/diff/260001/chrome/common/child_pr...
chrome/common/child_process_logging_win.cc:77: set_metrics_id_fn(client_info ?
client_info->client_id.c_str() : nullptr);
On 2016/06/28 02:40:45, sky wrote:
> Does SetMetricsClientId make a copy of the char*?
Yes. It eventually ends up here.
https://cs.chromium.org/chromium/src/components/crash/core/common/crash_keys....

[sky, 2016-06-28 16:42:05]

Ok, thanks for the clarification.

On Mon, Jun 27, 2016 at 8:15 PM,  <ananta@chromium.org> wrote:
> Currently it is all manual testing, and some individual unittests for
> portions
> of the code being run here.
>
> We would know quickly in Canary whether reports are coming in or not.
>
>
>
>
https://codereview.chromium.org/2088133002/diff/260001/chrome/common/child_pr...
> File chrome/common/child_process_logging_win.cc (right):
>
>
https://codereview.chromium.org/2088133002/diff/260001/chrome/common/child_pr...
> chrome/common/child_process_logging_win.cc:77:
> set_metrics_id_fn(client_info ? client_info->client_id.c_str() :
> nullptr);
> On 2016/06/28 02:40:45, sky wrote:
>> Does SetMetricsClientId make a copy of the char*?
> Yes. It eventually ends up here.
>
https://cs.chromium.org/chromium/src/components/crash/core/common/crash_keys....
>
> https://codereview.chromium.org/2088133002/

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[robertshield, 2016-06-29 02:42:55]

lg, one comment about where IAT patching is called from.

https://codereview.chromium.org/2088133002/diff/300001/chrome_elf/chrome_elf_...
File chrome_elf/chrome_elf_main.cc (right):

https://codereview.chromium.org/2088133002/diff/300001/chrome_elf/chrome_elf_...
chrome_elf/chrome_elf_main.cc:117: DisableSetUnhandledExceptionFilter();
This will be skipped if blacklist initialization fails, which doesn't seem right
since the process will otherwise continue normally.

If we also want dump information at the time it fails, I'd do it in a separate
__try/__except block.

[ananta, 2016-06-30 00:46:37]

The CQ bit was checked by ananta@chromium.org

[ananta, 2016-06-30 00:46:38]

The patchset sent to the CQ was uploaded after l-g-t-m from sky@chromium.org,
scottmg@chromium.org
Link to the patchset: https://codereview.chromium.org/2088133002/#ps400001
(title: "Fix build error")

[commit-bot: I haz the power, 2016-06-30 00:47:06]

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, 2016-06-30 00:56:55]

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

[commit-bot: I haz the power, 2016-06-30 00:56:56]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[ananta, 2016-06-30 01:00:36]

https://codereview.chromium.org/2088133002/diff/300001/chrome_elf/chrome_elf_...
File chrome_elf/chrome_elf_main.cc (right):

https://codereview.chromium.org/2088133002/diff/300001/chrome_elf/chrome_elf_...
chrome_elf/chrome_elf_main.cc:117: DisableSetUnhandledExceptionFilter();
On 2016/06/29 02:42:54, robertshield wrote:
> This will be skipped if blacklist initialization fails, which doesn't seem
right
> since the process will otherwise continue normally.
> 
> If we also want dump information at the time it fails, I'd do it in a separate
> __try/__except block. 

Done.

[ananta, 2016-06-30 01:01:31]

Description was changed from

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in
chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest.
This is via the exe name check.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

4. Added a function RegisterCrashKeysForDebugging to the
ChromeCrashReporterClient class on Windows
   to register crash keys. This is currently invoked from chrome_elf for
debugging purposes.

5. Changed the browser lib target to depend on chrome_elf:blacklist instead of
chrome_elf. This prevents chrome_elf
   from being implicitly loaded in processes other than chrome.exe

BUG=604923,crashpad:106
==========

to

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in
chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest.
This is via the exe name check.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

4. Added a function RegisterCrashKeysForDebugging to the
ChromeCrashReporterClient class on Windows
   to register crash keys. This is currently invoked from chrome_elf for
debugging purposes.

5. Changed the browser lib target to depend on chrome_elf:blacklist instead of
chrome_elf. This prevents chrome_elf
   from being implicitly loaded in processes other than chrome.exe

BUG=604923,crashpad:106, 568664
==========

[ananta, 2016-06-30 01:01:49]

Description was changed from

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in
chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest.
This is via the exe name check.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

4. Added a function RegisterCrashKeysForDebugging to the
ChromeCrashReporterClient class on Windows
   to register crash keys. This is currently invoked from chrome_elf for
debugging purposes.

5. Changed the browser lib target to depend on chrome_elf:blacklist instead of
chrome_elf. This prevents chrome_elf
   from being implicitly loaded in processes other than chrome.exe

BUG=604923,crashpad:106, 568664
==========

to

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in
chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest.
This is via the exe name check.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

4. Added a function RegisterCrashKeysForDebugging to the
ChromeCrashReporterClient class on Windows
   to register crash keys. This is currently invoked from chrome_elf for
debugging purposes.

5. Changed the browser lib target to depend on chrome_elf:blacklist instead of
chrome_elf. This prevents chrome_elf
   from being implicitly loaded in processes other than chrome.exe

BUG=604923,crashpad:106, 568664
TBR=robertshield
==========

[ananta, 2016-06-30 01:01:59]

The CQ bit was checked by ananta@chromium.org

[commit-bot: I haz the power, 2016-06-30 01:02:29]

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, 2016-06-30 01:08:02]

Description was changed from

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in
chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest.
This is via the exe name check.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

4. Added a function RegisterCrashKeysForDebugging to the
ChromeCrashReporterClient class on Windows
   to register crash keys. This is currently invoked from chrome_elf for
debugging purposes.

5. Changed the browser lib target to depend on chrome_elf:blacklist instead of
chrome_elf. This prevents chrome_elf
   from being implicitly loaded in processes other than chrome.exe

BUG=604923,crashpad:106, 568664
TBR=robertshield
==========

to

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in
chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest.
This is via the exe name check.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

4. Added a function RegisterCrashKeysForDebugging to the
ChromeCrashReporterClient class on Windows
   to register crash keys. This is currently invoked from chrome_elf for
debugging purposes.

5. Changed the browser lib target to depend on chrome_elf:blacklist instead of
chrome_elf. This prevents chrome_elf
   from being implicitly loaded in processes other than chrome.exe

BUG=604923,crashpad:106, 568664
TBR=robertshield
==========

[commit-bot: I haz the power, 2016-06-30 01:08:04]

Committed patchset #21 (id:400001)

[commit-bot: I haz the power, 2016-06-30 01:08:07]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-06-30 01:09:52]

Description was changed from

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in
chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest.
This is via the exe name check.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This 
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

4. Added a function RegisterCrashKeysForDebugging to the
ChromeCrashReporterClient class on Windows
   to register crash keys. This is currently invoked from chrome_elf for
debugging purposes.

5. Changed the browser lib target to depend on chrome_elf:blacklist instead of
chrome_elf. This prevents chrome_elf
   from being implicitly loaded in processes other than chrome.exe

BUG=604923,crashpad:106, 568664
TBR=robertshield
==========

to

==========
Switch chrome_elf exception handling from breakpad to crashpad.

Changes in this patch are as below:
1. chrome_elf: Removing breakpad and corresponding exception initialization
using breakpad. Registering
   crashpad as the exception handling mechanism in chrome_elf. We continue to
handle exceptions in chrome_elf
   DllMain and in the blacklist interception code as before, i.e. we use
crashpad to grab the dump and pass
   the exception to the next handler in the chain. I also added support in
chrome_elf to not initialize
   crashpad if it is being loaded in some tests. For e.g. the ELFImportsTest.
This is via the exe name check.

2. chrome.exe:- Removing crashpad exception registration. Also we need to
retrieve current exception reports information
   from chrome_elf instead of chrome.

3. Intercept the SetUnhandledExceptionFilter API in chrome_elf via IAT patching
on the exe and disallow the call. This
   is to prevent CRT from overwriting crashpads exception filter. I added a TODO
to see if we can use EAT patching or
   possibly sidestep if we can support 64 bit with it.

4. Added a function RegisterCrashKeysForDebugging to the
ChromeCrashReporterClient class on Windows
   to register crash keys. This is currently invoked from chrome_elf for
debugging purposes.

5. Changed the browser lib target to depend on chrome_elf:blacklist instead of
chrome_elf. This prevents chrome_elf
   from being implicitly loaded in processes other than chrome.exe

BUG=604923,crashpad:106, 568664
TBR=robertshield

Committed: https://crrev.com/34831427124fef3015106cfe6e94d35f3aa9e4f6
Cr-Commit-Position: refs/heads/master@{#403048}
==========

[commit-bot: I haz the power, 2016-06-30 01:09:54]

Patchset 21 (id:??) landed as
https://crrev.com/34831427124fef3015106cfe6e94d35f3aa9e4f6
Cr-Commit-Position: refs/heads/master@{#403048}

[Ken Russell (switch to Gerrit), 2016-06-30 01:49:23]

A revert of this CL (patchset #21 id:400001) has been created in
https://codereview.chromium.org/2108413002/ by kbr@chromium.org.

The reason for reverting is: Broke build:
https://build.chromium.org/p/chromium.win/builders/Win8%20GYP%20%28dbg%29/bui...

Seems likely the component build is broken by this change.
.