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.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).
 You may wish to add the -p option, if your version of addr2line supports it.