Control the behavior of failed assertions (
NS_ASSERTION and friends).
If you've given the
--enable-crash-on-assert switch to
configure, this environment variable is ignored.
- warn - This is equivalent to the default of simply spitting an error message to stderr and ringing the bell. (I think this is the default on Mac and Linux.)
- stack - In addition to ringing the bell and printing a warning, a stack trace is written to stderr. Be sure to run the output through tools/rb/fix_macosx_stack.py or tools/rb/fix_linux_stack.py before sharing it. These scripts take the log file that contains the stack trace as STDIN.
E.g., tools/rb/fix_linux_stack.py < logfile > sanitized_logfile
- suspend - The process-group is sent a SIGSTOP signal. This suspends all threads so that you can attach to the process with the debugger before the conditions that caused the assertion disappear.
- abort - This makes
assert(3)—an assertion failure calls
abort—and is equivalent to building with
- trap or break - Break into the debugger, if one is attached. If the process is not being debugged, behavior depends on the OS. On Windows, this will show the usual modal dialog box offering to debug or abort the process, or ignore the error. On other OSes, if no debugger is attached, it will crash.
- stack-and-abort - The combination platter. Prints a warning, rings the bell, dumps the stack, and aborts. (new in Mozilla 1.9 since August 2007)
Assuming you're using bash: