50.6 When Emacs Crashes

Emacs is not supposed to crash, but if it does, it produces a crash report prior to exiting. The crash report is printed to the standard error stream. If Emacs was started from a graphical desktop, the standard error stream is commonly redirected to a file such as ~/.xsession-errors, so you can look for the crash report there.

The format of the crash report depends on the platform. On some platforms, such as those using the GNU C Library, the crash report includes a backtrace describing the execution state prior to crashing, which can be used to help debug the crash. Here is an example:

Fatal error 11: Segmentation fault
Backtrace:
emacs[0x5094e4]
emacs[0x4ed3e6]
emacs[0x4ed504]
/lib64/libpthread.so.0[0x375220efe0]
/lib64/libpthread.so.0(read+0xe)[0x375220e08e]
emacs[0x509af6]
emacs[0x5acc26]
…

The number ‘11’ is the system signal number corresponding to the crash—in this case a segmentation fault. The hexadecimal numbers are program addresses, which can be associated with source code lines using a debugging tool. For example, the GDB command ‘list *0x509af6’ prints the source-code lines corresponding to the ‘emacs[0x509af6]’ entry. If your system has the addr2line utility, the following shell command outputs a backtrace with source-code line numbers:

sed -n 's/.*\[\(.*\)]$/\1/p' backtrace |
  addr2line -C -f -i -e bindir/emacs

Here, backtrace is the name of a text file containing a copy of the backtrace, and bindir is the name of the directory that contains the Emacs executable.¹⁸

Optionally, Emacs can generate a core dump when it crashes. A core dump is a file containing voluminous data about the state of the program prior to the crash, usually examined by loading it into a debugger such as GDB. On many platforms, core dumps are disabled by default, and you must explicitly enable them by running the shell command ‘ulimit -c unlimited’ (e.g., in your shell startup script).