Make AboutCrash handler crash directly.

Make AboutCrash handler crash directly.

Was inadvertantly changed to use CHECK(false).  Reverting to crash
directly so that the crash signature is more useful
(AboutHandler::AboutCrash rather than BreakDebugger).

BUG=none
TEST=about:crash still crashes the renderer.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=91448

[msw, 2011-07-01 19:47:44]

LGTM. Sorry for any inconvenience.

[Scott Hess - ex-Googler, 2011-07-01 19:59:01]

http://codereview.chromium.org/7301003/diff/1/chrome/renderer/about_handler.cc
File chrome/renderer/about_handler.cc (right):

http://codereview.chromium.org/7301003/diff/1/chrome/renderer/about_handler.c...
chrome/renderer/about_handler.cc:48: *zero = 0;
In an email thread, msw said:
> I think someone recommended using volatile if we
> kept the null ptr deref, this would be a good opportunity
> to do just that.

Would the use of volatile be to prevent the compiler from realizing that this is
undefined behavior?

Regardless, it seems reasonable to add a NOTREACHED() after this, just in case.

[msw, 2011-07-01 20:04:47]

On 2011/07/01 19:59:01, shess wrote:
> http://codereview.chromium.org/7301003/diff/1/chrome/renderer/about_handler.cc
> File chrome/renderer/about_handler.cc (right):
> 
>
http://codereview.chromium.org/7301003/diff/1/chrome/renderer/about_handler.c...
> chrome/renderer/about_handler.cc:48: *zero = 0;
> In an email thread, msw said:
> > I think someone recommended using volatile if we
> > kept the null ptr deref, this would be a good opportunity
> > to do just that.
> 
> Would the use of volatile be to prevent the compiler from realizing that this
is
> undefined behavior?
> 
> Regardless, it seems reasonable to add a NOTREACHED() after this, just in
case.

Yes, abarth made the original suggestion and Nico just explained that Clang will
optimize out writes to null pointers, so volatile is the way to go. The extra
NOTREACHED seems like a good idea too.

[Nico, 2011-07-03 19:34:37]

http://codereview.chromium.org/7301003/diff/6001/chrome/renderer/about_handle...
File chrome/renderer/about_handler.cc (right):

http://codereview.chromium.org/7301003/diff/6001/chrome/renderer/about_handle...
chrome/renderer/about_handler.cc:52: // optimizes it away.
I don't think that can happen with a volatile pointer, 'cause volatile means
"contents can change in a volatile manner (e.g. when the pointer really reads
from a hardware device)"?