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!
