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