1094483 - Force the MOZ_REALLY_CRASH line number to show up in crashes

Status: RESOLVED DUPLICATE of bug 1119030

(Core :: MFBT, defect)

Description

[Steve Fink [:sfink] [:s:]]

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.

Comment 1

[Steve Fink [:sfink] [:s:]]

Attachment: Force the MOZ_REALLY_CRASH line number to show up in crashes

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.

Comment 2

[Steve Fink [:sfink] [:s:]]

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.

Comment 3

[Mike Hommey [:glandium]]

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...

Comment 4

[Chris Peterson [:cpeterson]]

dmajor landed the same fix in bug 1119030 (to prevent MSVC from deduping MOZ_CRASH calls).