MOZ_CRASH() doesn't always yield clear stack traces in our crash stats, because it doesn't push a stack frame before crashing. Although many callers of MOZ_CRASH() wrap it in a not-inlined function (see e.g. bug 787675), not all callers do. Anyway, callers shouldn't have to jump through hoops in order to get decent crash stats.

Hrm. *Not* pushing a frame was in fact the whole point of having it as a macro, because sometimes we weren't backtracing the first frame correctly and would end up skipping the important frame.

Ah, interesting! I guess we could wontfix this and continue to fix it on a case-by-case basis. Or we could have a MOZ_CRASH_INLINED() and MOZ_CRASH_OUTOFLINE(), which is kind of ugly. (Also, I'm having difficulty figuring out the build-fu required to make this bug work as-is.)

MOZ_CRASH() was also made to crash completely inline so that when debugging, hitting an assertion will park the debugger on the assertion in question. Useful crash stacks is one good, but you have to trade it off against that other good. It certainly helps me a lot as a SpiderMonkey developer to not have to type "up N", for some N (which was non-constant over time until we made this change!), to get to where things actually went wrong.

I would be totally fine with a solution which added a stack frame only in release builds, or builds where the crash reporter was enabled, or something.

Or we could include the line number of the MOZ_CRASH in as the crash annotation (as NS_RUNTIMEABORT does still, I think), so that any inlining weirdness wouldn't be directly relevant.