Closed
Bug 910074
Opened 11 years ago
Closed 11 years ago
Crash reporter annotations added in bug 867530 are not actually added
Categories
(Toolkit :: Startup and Profile System, defect)
Toolkit
Startup and Profile System
Tracking
()
RESOLVED
FIXED
mozilla26
People
(Reporter: glandium, Assigned: glandium)
References
Details
Attachments
(1 file, 1 obsolete file)
Caught this when looking around at the code for something else: AnnotateCrashReport does nothing when the CrashReporter::GetEnabled() returns false, which it does until SetExceptionHandler is called. But the AnnotateCrashReport calls added in bug 867530 are before SetExceptionHandler.
Assignee | ||
Comment 1•11 years ago
|
||
Attachment #796432 -
Flags: review?(benjamin)
Comment 2•11 years ago
|
||
I don't understand how this code is supposed to work *at all*, since the normal startup "enable exception handling" code path doesn't actually go through nsXULAppInfo::SetEnabled. That's just for handling setting the .enabled property on nsICrashReporter.
Assignee | ||
Comment 3•11 years ago
|
||
Comment on attachment 796432 [details] [diff] [review] Move crash reporter annotations added in bug 867530 after SetExceptionHandler call Indeed.
Attachment #796432 -
Flags: review?(benjamin)
Assignee | ||
Comment 4•11 years ago
|
||
Attachment #796654 -
Flags: review?(ted)
Assignee | ||
Updated•11 years ago
|
Attachment #796432 -
Attachment is obsolete: true
Comment 5•11 years ago
|
||
Comment on attachment 796654 [details] [diff] [review] Move crash reporter annotations added in bug 867530 after both SetExceptionHandler call and xpcom initialization Review of attachment 796654 [details] [diff] [review]: ----------------------------------------------------------------- ::: toolkit/xre/nsAppRunner.cpp @@ +3680,5 @@ > + // Needs to be set after xpcom initialization. > + CrashReporter::AnnotateCrashReport(NS_LITERAL_CSTRING("FramePoisonBase"), > + nsPrintfCString("%.16llx", uint64_t(gMozillaPoisonBase))); > + CrashReporter::AnnotateCrashReport(NS_LITERAL_CSTRING("FramePoisonSize"), > + nsPrintfCString("%lu", uint32_t(gMozillaPoisonSize))); These won't get annotated in xpcshell, but I don't think that matters. (In the other location they would only get annotated in xpcshell.)
Attachment #796654 -
Flags: review?(ted) → review+
Assignee | ||
Comment 6•11 years ago
|
||
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #5) > These won't get annotated in xpcshell, but I don't think that matters. (In > the other location they would only get annotated in xpcshell.) Note most nsAppRunner annotations are above that, so they too won't get annotated in xpcshell.
Comment 7•11 years ago
|
||
Yes, but most of those come from the appdata, which makes sense. It's not a particularly big deal, I just wanted to point that out.
Assignee | ||
Comment 8•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/86f568d2d467
Comment 9•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/86f568d2d467
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
You need to log in
before you can comment on or make changes to this bug.
Description
•