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 on a GNU or Unix system, the standard error stream is commonly redirected to a file such as ~/.xsession-errors, so you can look for the crash report there. On MS-Windows, the crash report is written to a file named emacs_backtrace.txt in the current directory of the Emacs process, in addition to the standard error stream.
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 for a GNU system:
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 -p -e bindir/emacs-binary
Here, backtrace is the name of a text file containing a copy of the backtrace, bindir is the name of the directory that contains the Emacs executable, and emacs-binary is the name of the Emacs executable file, normally emacs on GNU and Unix systems and emacs.exe on MS-Windows and MS-DOS. Omit the -p option if your version of addr2line is too old to have it.
Optionally, Emacs can generate a core dump when it crashes, on systems that support core files. 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).