Get More Details when Emacs Crashes

As I live on the edge (i.e. on Emacs master branch), it happens from time to time that Emacs crashes after an update – but not often enough that I can remember how to provide enough details for maintainers to investigate.

So here are some notes on how to proceed.

First compile Emacs with enough debugging information: this requires the '-O0 -g3' flags to be passed to configure:

 CFLAGS="-g3 -O0" CXXFLAGS="-g3 -O0" ./configure --with-cairo  --with-modules . . .
make && sudo make install

(You don’t have to make install, but the following assumes you have.

To execute with gdb:

gdb emacs

gdb starts, you can then run Emacs, passing arguments as well by calling run at the prompt, and appending the args:

(gdb) run -Q --load init-ido.el

This starts emacs with a init file (here init-ido.el) that you need to create, and which typically would contain the recipe producing the issue. A full backtrace can be obtained by running the following command:

(gdb) bt full

To also get a Lisp backtrace, you need to use src/.gdbinit, by running gdb in the src directory. The Lisp backtrace can be obtained by executing:

(gdb) xbacktrace

To set a breakpoint, you can run the following – prior to running Emacs, if needs be:

(gdb) b Factive_minibuffer_window

You can then print the value of various variables, using the p command:

(gdb) p minibuf_level
$1 = 0

You may need to select the correct frame first to be able to view the relevant variables:

(gdb) select-frame 2

To report the bug you can gather all these details, and add them to a bug report that you can kick off with M-x report-emacs-bug in Emacs). Hopefully this will help everyone save some time next time another nasty crash occurs!