[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: firefox 58.0 "Gah. Your tab just crashed"
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
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
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
Main Index |
Thread Index |