Closed
Bug 910074
Opened 12 years ago
Closed 12 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•12 years ago
|
||
Attachment #796432 -
Flags: review?(benjamin)
Comment 2•12 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•12 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•12 years ago
|
||
Attachment #796654 -
Flags: review?(ted)
Assignee | ||
Updated•12 years ago
|
Attachment #796432 -
Attachment is obsolete: true
Comment 5•12 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•12 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•12 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•12 years ago
|
||
Comment 9•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
You need to log in
before you can comment on or make changes to this bug.
Description
•