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)
Tracking
()
NEW
People
(Reporter: jdm, Unassigned)
Details
Attachments
(1 file)
(deleted),
patch
|
cjones
:
review-
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 2•14 years ago
|
||
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-
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•