XPCOM_DEBUG_BREAK

Environment variable

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.

Values:

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 NS_ASSERTION act like assert(3)—an assertion failure calls abort—and is equivalent to building with --enable-crash-on-assert.
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:

export XPCOM_DEBUG_BREAK=stack

Document Tags and Contributors