Next: , Previous: Memory Full, Up: Lossage

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

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.1

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).


[1] You may wish to add the -p option, if your version of addr2line supports it.