Re: firefox 58.0 "Gah. Your tab just crashed"

[David Brownlee <abs%absd.org@localhost>]

On 2 February 2018 at 20:30, David Brownlee <abs%absd.org@localhost> wrote:
> (First thought would be to see if you can make MOZ_CRASH() log its
> argument before exploding, which while generally helpful is unlikely
> to directly help)

/*
 * MOZ_CRASH([explanation-string]) crashes the program, plain and simple, in a
 * Breakpad-compatible way, in both debug and release builds.
 *
 * MOZ_CRASH is a good solution for "handling" failure cases when you're
 * unwilling or unable to handle them more cleanly -- for OOM, for likely memory
 * corruption, and so on.  It's also a good solution if you need safe behavior
 * in release builds as well as debug builds.  But if the failure is one that
 * should be debugged and fixed, MOZ_ASSERT is generally preferable.
 *
 * The optional explanation-string, if provided, must be a string literal
 * explaining why we're crashing.  This argument is intended for use with
 * MOZ_CRASH() calls whose rationale is non-obvious; don't use it if it's
 * obvious why we're crashing.
 *
 * If we're a DEBUG build and we crash at a MOZ_CRASH which provides an
 * explanation-string, we print the string to stderr.  Otherwise, we don't
 * print anything; this is because we want MOZ_CRASH to be 100% safe in release
 * builds, and it's hard to print to stderr safely when memory might have been
 * corrupted.
 */

I could take on a puzzled expression and ask about the relative risk
of calling write(STDERR_FILENO, ...) in a release build, but I'm sure
someone could come up with a memory corruption case where that would
be bad.

On the other hand if you have a core dump then the crash reason should
be in gMozCrashReason - Martin, worth adding to the debug-info notes?

Having said that I think there might be a good argument for tweaking a
debug-info build to include output from MOZ_CRASH() - or even breaking
it out into a separate build option, but that is orthogonal to the
original issue...

David