Closed Bug 1094483 Opened 7 years ago Closed 6 years ago
Force the MOZ
_REALLY _CRASH line number to show up in crashes
Currently, the code generated for MOZ_CRASH is identical ifndef DEBUG, because all traces of __FILE__ and __LINE__ are eliminated. This allows the compiler to jump to shared code for multiple MOZ_CRASHes, which makes it impossible to figure out exactly what one was hit in a release build.
One trick would be to change *nullptr = 123 to *nullptr = __LINE__. Sadly, this will still require inspecting the minidump rather than just looking at the JSON output, but at least it's something. (A more clever variant might be to set some random register to __LINE__ before crashing, but I don't want to do the work to make that portable.) All of this seems like depending on nonsense a little bit, since *nullptr = anything is undefined behavior AIUI, but oh well.
Attachment #8517768 - Flags: review?(jwalden+bmo)
For the record, in the specific case I was looking at where people were suspecting that MSVC was coalescing MOZ_CRASH calls, it was not. The generated code clearly had a separate copies of the int 3; *0 = 123 pattern. And the tools were identifying the correct line numbers. So I'm not sure if this patch really matters in practice, though it's a nice way to double-check instead of relying on faith-based debugging.
For the record, I just had the opposite experience on mac: the generated code did not use a separate copy, but both macros calls were in the same function, so that's kind of an expected optimization. And the debugger was always giving the line of the second one, while the crash was actually triggered by the first one...
Attachment #8517768 - Flags: review?(jwalden+bmo) → review+
dmajor landed the same fix in bug 1119030 (to prevent MSVC from deduping MOZ_CRASH calls).
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1119030
You need to log in before you can comment on or make changes to this bug.