619227 - Don't set ah_crap_handler with MOZ_CRASHREPORTER present

Status: NEW

(Core :: General, defect)

Description

[Josh Matthews [:jdm]]

In debug builds, building with --enable-crashreporter and running with MOZ_CRASHREPORTER still doesn't enable crash reports for content processes because the ah_crap signal handler stomps on the breakpad one.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This sounds eerily familiar but I don't remember having filed it before.

Comment 2

[Josh Matthews [:jdm]]

Attachment: Don't set ah_crap_handler when MOZ_CRASHREPORTER is present.

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Comment on attachment 497691 [details] [diff] [review]
Don't set ah_crap_handler when MOZ_CRASHREPORTER is present.

This doesn't handle all the crashreporter enable/disable cases.  Whether it's enabled is a fairly tricky business, wouldn't recommend attempting to duplicate the logic here.

Instead, something like nsExceptionHandler::GetEnabled() that works in content processes (i.e., that just returns |gExceptionHandler != nsnull|) seems like a  better solution.  Ted could advise on name, but nsExceptionHandler::HasInstalledHandler() should be fine, and will even do the right thing in the chrome process (it'll return false on startup and breakpad will stomp the initial handler).