Make OOP mac crashreporting exit after writing dump

I stumbled over this in Mozilla bug 848075, it's causing our tests to hang
occasionally. The OOP minidump writing code path in the Mac ExceptionHandler
doesn't honor exit_after_write, so it calls back into exc_server, which winds up
calling dlsym in libkern to find catch_exception_raise. Unfortunately dlsym can
malloc, which can deadlock because the other threads are suspended. Making the
OOP code path behave similarly to the in-process path fixes this issue.

[Mark Mentovai]

http://breakpad.appspot.com/538002/diff/1/src/client/mac/handler/exception_ha...
File src/client/mac/handler/exception_handler.cc (right):

http://breakpad.appspot.com/538002/diff/1/src/client/mac/handler/exception_ha...
src/client/mac/handler/exception_handler.cc:372: _exit(exception_type);
I don’t think this will prevent Apple’s Crash Reporter from also picking up the
crash when BREAKPAD_SEND_AND_EXIT is false, right? Can you confirm that?

[Ted Mielczarek]

http://breakpad.appspot.com/538002/diff/1/src/client/mac/handler/exception_ha...
File src/client/mac/handler/exception_handler.cc (right):

http://breakpad.appspot.com/538002/diff/1/src/client/mac/handler/exception_ha...
src/client/mac/handler/exception_handler.cc:372: _exit(exception_type);
On 2013/03/06 19:44:29, Mark Mentovai wrote:
> I don’t think this will prevent Apple’s Crash Reporter from also picking up
the
> crash when BREAKPAD_SEND_AND_EXIT is false, right? Can you confirm that?

The Breakpad framework doesn't actually use this code, AFAIK, it uses a direct
callback and does its own Mach messaging. I would like to refactor that to share
code at some point but it's never been a high priority.

[Mark Mentovai]

LGTM