win: Fix not setting crash keys in non-component build

win: Fix not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/) is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
'base'.

Example static_library: crash/7e66260061a696bb (noting that Fields
include switches, extensions, etc.)
Example shared_library: crash/708ab5c5f980e0df

R=mark@chromium.org
TBR=cpu@chromium.org
BUG=568189, 546288
Committed: https://crrev.com/f2f2fec741ee1eb7979eab24c5558d6f5efeb020
Cr-Commit-Position: refs/heads/master@{#364501}

[scottmg, 2015-12-10 00:30:15]

Description was changed from

==========
win: Fix renderer not setting crash keys in non-component build

BUG=568189, 546288
==========

to

==========
win: Fix renderer not setting crash keys in non-component build

This resurrects some of the code removed in
https://codereview.chromium.org/1479283002/.

In the renderer, in static_library builds the crash keys were
getting set into the 

BUG=568189, 546288
==========

[scottmg, 2015-12-10 00:31:13]

Description was changed from

==========
win: Fix renderer not setting crash keys in non-component build

This resurrects some of the code removed in
https://codereview.chromium.org/1479283002/.

In the renderer, in static_library builds the crash keys were
getting set into the 

BUG=568189, 546288
==========

to

==========
win: Fix renderer not setting crash keys in non-component build

This resurrects some of the code removed in
https://codereview.chromium.org/1479283002/.

In the renderer, in static_library builds the crash keys were
getting set into the 

Example: crash/7e66260061a696bb (noting that Fields include switches,
extensions, etc.)

BUG=568189, 546288
==========

[scottmg, 2015-12-10 00:33:10]

Description was changed from

==========
win: Fix renderer not setting crash keys in non-component build

This resurrects some of the code removed in
https://codereview.chromium.org/1479283002/.

In the renderer, in static_library builds the crash keys were
getting set into the 

Example: crash/7e66260061a696bb (noting that Fields include switches,
extensions, etc.)

BUG=568189, 546288
==========

to

==========
win: Fix renderer not setting crash keys in non-component build

This resurrects some of the code removed in
https://codereview.chromium.org/1479283002/.

Broken at https://codereview.chromium.org/1481703002/ in static_library builds.

Thye 

Example: crash/7e66260061a696bb (noting that Fields include switches,
extensions, etc.)

BUG=568189, 546288
==========

[scottmg, 2015-12-10 00:33:56]

Description was changed from

==========
win: Fix renderer not setting crash keys in non-component build

This resurrects some of the code removed in
https://codereview.chromium.org/1479283002/.

Broken at https://codereview.chromium.org/1481703002/ in static_library builds.

Thye 

Example: crash/7e66260061a696bb (noting that Fields include switches,
extensions, etc.)

BUG=568189, 546288
==========

to

==========
win: Fix renderer not setting crash keys in non-component build

This resurrects some of the code removed in
https://codereview.chromium.org/1479283002/.

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

The g_simple_

Example: crash/7e66260061a696bb (noting that Fields include switches,
extensions, etc.)

BUG=568189, 546288
==========

[scottmg, 2015-12-10 00:39:12]

Description was changed from

==========
win: Fix renderer not setting crash keys in non-component build

This resurrects some of the code removed in
https://codereview.chromium.org/1479283002/.

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

The g_simple_

Example: crash/7e66260061a696bb (noting that Fields include switches,
extensions, etc.)

BUG=568189, 546288
==========

to

==========
win: Fix renderer not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/ is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
base.

Example: crash/7e66260061a696bb (noting that Fields include switches,
extensions, etc.)

BUG=568189, 546288
==========

[scottmg, 2015-12-10 00:49:08]

Description was changed from

==========
win: Fix renderer not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/ is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
base.

Example: crash/7e66260061a696bb (noting that Fields include switches,
extensions, etc.)

BUG=568189, 546288
==========

to

==========
win: Fix renderer not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/) is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
'base'.

Example: crash/7e66260061a696bb (noting that Fields include switches,
extensions, etc.)

BUG=568189, 546288
==========

[scottmg, 2015-12-10 00:49:38]

Description was changed from

==========
win: Fix renderer not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/) is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
'base'.

Example: crash/7e66260061a696bb (noting that Fields include switches,
extensions, etc.)

BUG=568189, 546288
==========

to

==========
win: Fix renderer not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/) is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
'base'.

Example static_library: crash/7e66260061a696bb (noting that Fields include
switches,
extensions, etc.)
Example shared_library: crash/708ab5c5f980e0df

BUG=568189, 546288
==========

[scottmg, 2015-12-10 00:49:53]

Description was changed from

==========
win: Fix renderer not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/) is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
'base'.

Example static_library: crash/7e66260061a696bb (noting that Fields include
switches,
extensions, etc.)
Example shared_library: crash/708ab5c5f980e0df

BUG=568189, 546288
==========

to

==========
win: Fix renderer not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/) is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
'base'.

Example static_library: crash/7e66260061a696bb (noting that Fields
include switches, extensions, etc.)
Example shared_library: crash/708ab5c5f980e0df

BUG=568189, 546288
==========

[scottmg, 2015-12-10 00:50:05]

Description was changed from

==========
win: Fix renderer not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/) is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
'base'.

Example static_library: crash/7e66260061a696bb (noting that Fields
include switches, extensions, etc.)
Example shared_library: crash/708ab5c5f980e0df

BUG=568189, 546288
==========

to

==========
win: Fix not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/) is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
'base'.

Example static_library: crash/7e66260061a696bb (noting that Fields
include switches, extensions, etc.)
Example shared_library: crash/708ab5c5f980e0df

BUG=568189, 546288
==========

[scottmg, 2015-12-10 00:51:04]

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

[scottmg, 2015-12-10 00:51:40]

I was totally wrong in https://codereview.chromium.org/1481703002/#msg20. :( It
does indeed go through there, but only in shared_library, or for keys set from
the exe.

[scottmg, 2015-12-10 01:11:29]

https://codereview.chromium.org/1517503004/diff/40001/components/crash/conten...
File components/crash/content/app/crashpad.cc (right):

https://codereview.chromium.org/1517503004/diff/40001/components/crash/conten...
components/crash/content/app/crashpad.cc:255: const wchar_t* value) {
These also happen to be functions that SyzyASAN relies on existing.

[Mark Mentovai, 2015-12-10 02:19:57]

LGTM

Freakin’ component=shared_library build strikes again!

[scottmg, 2015-12-10 19:08:31]

The test initialization of crash keys is a mess. I filed
https://code.google.com/p/chromium/issues/detail?id=568664, and removed
InitializeCrashpad() from chrome_test_launcher.cc in this CL.

I realized later that in Breakpad-land, Breakpad wasn't getting initialized in
tests because it was in the dll loader here:
https://codereview.chromium.org/1479283002/diff/100001/chrome/app/main_dll_lo...
(which is only in chrome.exe).

The code in child_process_logging_win still gets called, but doesn't do anything
in test binaries, which was some of my confusion when I did the original switch.

[scottmg, 2015-12-10 20:00:21]

The CQ bit was checked by scottmg@chromium.org

[scottmg, 2015-12-10 20:00:21]

The patchset sent to the CQ was uploaded after l-g-t-m from mark@chromium.org
Link to the patchset: https://codereview.chromium.org/1517503004/#ps80001
(title: "don't initialize in tests")

[commit-bot: I haz the power, 2015-12-10 20:04:52]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1517503004/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1517503004/80001

[commit-bot: I haz the power, 2015-12-10 20:23:37]

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

[commit-bot: I haz the power, 2015-12-10 20:23:39]

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

[scottmg, 2015-12-10 20:29:26]

Description was changed from

==========
win: Fix not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/) is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
'base'.

Example static_library: crash/7e66260061a696bb (noting that Fields
include switches, extensions, etc.)
Example shared_library: crash/708ab5c5f980e0df

BUG=568189, 546288
==========

to

==========
win: Fix not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/) is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
'base'.

Example static_library: crash/7e66260061a696bb (noting that Fields
include switches, extensions, etc.)
Example shared_library: crash/708ab5c5f980e0df

R=mark@chromium.org
TBR=cpu@chromium.org
BUG=568189, 546288
==========

[scottmg, 2015-12-10 20:29:37]

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

[scottmg, 2015-12-10 20:32:04]

+cpu for owners

[scottmg, 2015-12-10 20:32:09]

The CQ bit was checked by scottmg@chromium.org

[commit-bot: I haz the power, 2015-12-10 20:35:22]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1517503004/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1517503004/80001

[commit-bot: I haz the power, 2015-12-10 22:18:45]

Description was changed from

==========
win: Fix not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/) is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
'base'.

Example static_library: crash/7e66260061a696bb (noting that Fields
include switches, extensions, etc.)
Example shared_library: crash/708ab5c5f980e0df

R=mark@chromium.org
TBR=cpu@chromium.org
BUG=568189, 546288
==========

to

==========
win: Fix not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/) is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
'base'.

Example static_library: crash/7e66260061a696bb (noting that Fields
include switches, extensions, etc.)
Example shared_library: crash/708ab5c5f980e0df

R=mark@chromium.org
TBR=cpu@chromium.org
BUG=568189, 546288
==========

[commit-bot: I haz the power, 2015-12-10 22:18:45]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2015-12-10 22:19:27]

Description was changed from

==========
win: Fix not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/) is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
'base'.

Example static_library: crash/7e66260061a696bb (noting that Fields
include switches, extensions, etc.)
Example shared_library: crash/708ab5c5f980e0df

R=mark@chromium.org
TBR=cpu@chromium.org
BUG=568189, 546288
==========

to

==========
win: Fix not setting crash keys in non-component build

This was broken at https://codereview.chromium.org/1481703002/ in
static_library builds.

base/debug/crash_logging.cc silently ignores key setting if there's not
a key setting function set to it. When crashpad moved to the exe,
everything sort of seemed OK (and a few keys got set because they're set
in crashpad.cc in the exe). But any set from the dlls went into their
copy of base/debug/crash_logging.cc which didn't have logging set up in
crashpad.cc because it only initialized the globals in the exe. The fix
(resurrected from code removed in
https://codereview.chromium.org/1479283002/) is to have the DLLs set
their own function to call back into the exe.

This doesn't occur in shared_library builds because there's only one
'base'.

Example static_library: crash/7e66260061a696bb (noting that Fields
include switches, extensions, etc.)
Example shared_library: crash/708ab5c5f980e0df

R=mark@chromium.org
TBR=cpu@chromium.org
BUG=568189, 546288

Committed: https://crrev.com/f2f2fec741ee1eb7979eab24c5558d6f5efeb020
Cr-Commit-Position: refs/heads/master@{#364501}
==========

[commit-bot: I haz the power, 2015-12-10 22:19:28]

Patchset 5 (id:??) landed as
https://crrev.com/f2f2fec741ee1eb7979eab24c5558d6f5efeb020
Cr-Commit-Position: refs/heads/master@{#364501}