Make sure unexpected exit paths generate crash dumps for the browser.

Make sure unexpected exit paths generate crash dumps for the browser.

Right now it is possible for some random code to directly terminate the
browser process without generating a crash dump. This CL should fix that.

BUG=none
TEST=none
R=jam@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=217049

[rvargas (doing something else), 2013-08-08 00:56:20]

Maybe ChromeMain is a better place to do this but at this point I want to apply
this only to the browser process and see how it goes.

[jam, 2013-08-08 02:52:39]

Can this be done at the chrome layer? It seems that this something that's
specific to the chrome app

[rvargas (doing something else), 2013-08-08 19:21:12]

On 2013/08/08 02:52:39, jam wrote:
> Can this be done at the chrome layer? It seems that this something that's
> specific to the chrome app

I hope you mean chrome_main.cc and not chrome_browser_main.cc.

Ideally this should armed as early as possible once chrome.dll is loaded, and
disarmed as late as possible. That way, it covers most of the initialization and
shutdown code.

My expectation is to run this code on canary/dev and see if we get a spike on
crash reports; fix, revert as needed and when we are comfortable with it, move
it to ChromeMain so that we do the same for all process types. Ideally that
could be as early as next week, but that really depends on what we find.

Thanks.

[jam, 2013-08-08 20:55:21]

On 2013/08/08 19:21:12, rvargas wrote:
> On 2013/08/08 02:52:39, jam wrote:
> > Can this be done at the chrome layer? It seems that this something that's
> > specific to the chrome app
> 
> I hope you mean chrome_main.cc and not chrome_browser_main.cc.

I mean in src/chrome as opposed to src/content

> 
> Ideally this should armed as early as possible once chrome.dll is loaded, and
> disarmed as late as possible. That way, it covers most of the initialization
and
> shutdown code.
> 
> My expectation is to run this code on canary/dev and see if we get a spike on
> crash reports; fix, revert as needed and when we are comfortable with it, move
> it to ChromeMain so that we do the same for all process types. Ideally that
> could be as early as next week, but that really depends on what we find.
> 
> Thanks.

[rvargas (doing something else), 2013-08-08 21:22:20]

On 2013/08/08 20:55:21, jam wrote:
> On 2013/08/08 19:21:12, rvargas wrote:
> > On 2013/08/08 02:52:39, jam wrote:
> > > Can this be done at the chrome layer? It seems that this something that's
> > > specific to the chrome app
> > 
> > I hope you mean chrome_main.cc and not chrome_browser_main.cc.
> 
> I mean in src/chrome as opposed to src/content

Sure, both of those files live on src/chrome not src/content. I can add a TODO
to move the code to ChromeMain. If you think that's unacceptable, I guess I can
move the code right away, but I would prefer taking things slowly :)


> 
> > 
> > Ideally this should armed as early as possible once chrome.dll is loaded,
and
> > disarmed as late as possible. That way, it covers most of the initialization
> and
> > shutdown code.
> > 
> > My expectation is to run this code on canary/dev and see if we get a spike
on
> > crash reports; fix, revert as needed and when we are comfortable with it,
move
> > it to ChromeMain so that we do the same for all process types. Ideally that
> > could be as early as next week, but that really depends on what we find.
> > 
> > Thanks.

[jam, 2013-08-09 23:37:54]

ok, lgtm

[rvargas (doing something else), 2013-08-12 19:49:58]

Committed patchset #1 manually as r217049 (presubmit successful).