For example, there's http://hg.mozilla.org/releases/mozilla-beta/annotate/fb3494d06dfb/ipc/glue/ProtocolUtils.cpp#l332 which contains useful debugging information. Unfortunately we end up in http://hg.mozilla.org/releases/mozilla-beta/annotate/fb3494d06dfb/memory/mozalloc/mozalloc_abort.cpp#l33 which dumps the message on the floor if we're not looking at a terminal window. Could we call AnnotateCrashReport from here?
I guess the fact that it's in mozalloc could complicate that...
Looks like bug 1236108 is related prior art, but focuses strictly on providing a handler that's called when OOM occurs.
(In reply to Josh Matthews [:jdm] from comment #2) > Looks like bug 1236108 is related prior art, but focuses strictly on > providing a handler that's called when OOM occurs. I also added support for the "reason" string that is reported by AnnotateMozCrashReason. I *think* NS_RUNTIMEABORT uses that. This might work once bug 1256541 is merged.
You're right, it calls NS_DebugBreak which uses that.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1236108
No, that's a lie, it does not.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Bug 1049275 made it so that NS_RUNTIMEABORT doesn't annotate the crash report in the child process, but it seems like MOZ_CRASH is now doing thing, so maybe NS_RUNTIMEABORT could do the same thing? Or is MOZ_CRASH not safe to call from IPC code?
Component: General → Breakpad Integration
Product: Core → Toolkit
Summary: Annotate the crash report with the message passed to NS_RUNTIMEABORT → NS_RUNTIMEABORT and ipc::FatalError don't annotate crash reports in the child process
Bill looked at this a bit and I think this is easy to fix. Or at least improve.
Assignee: nobody → continuation
MOZ_CRASH is always safe to call, it's just a macro expansion to a crash.
You need to log in before you can comment on or make changes to this bug.