Open Bug 619227 Opened 14 years ago Updated 2 years ago

Don't set ah_crap_handler with MOZ_CRASHREPORTER present

Categories

(Core :: General, defect)

x86
Linux
defect

Tracking

()

People

(Reporter: jdm, Unassigned)

Details

Attachments

(1 file)

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.
This sounds eerily familiar but I don't remember having filed it before.
Attachment #497691 - Flags: review?(jones.chris.g)
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).
Attachment #497691 - Flags: review?(jones.chris.g) → review-
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: