2.1: Trouble Shooting

Q2.1.1: Help! SXEmacs just crashed on me!

First of all, don’t panic. Whenever SXEmacs crashes, it tries extremely hard to auto-save all of your files before dying. The main time that this will not happen is if the machine physically lost power or if you killed the SXEmacs process using kill -9. The next time you try to edit those files, you will be informed that a more recent auto-save file exists. You can use M-x recover-file to retrieve the auto-saved version of the file.

You can use the command M-x recover-session after a crash to pick up where you left off.

Now, SXEmacs is not perfect, and there may occasionally be times, or particular sequences of actions, that cause it to crash. If you can come up with a reproducible way of doing this (or even if you have a pretty good memory of exactly what you were doing at the time), the maintainers would be very interested in knowing about it. The best way to report a bug is using M-x report-sxemacs-bug (or by selecting ‘Send Bug Report...’ from the Help menu). If that won’t work (e.g. you can’t get SXEmacs working at all), send ordinary mail to sxemacs-devel@sxemacs.org. MAKE SURE to include the output from the crash, especially including the Lisp backtrace, as well as the SXEmacs configuration from M-x describe-installation (or equivalently, the file Installation in the top of the build tree).

If at all possible, include a C stack backtrace of the core dump that was produced. This shows where exactly things went wrong, and makes it much easier to diagnose problems. To do this under Unix, you need to locate the core file (it’s called core, and is usually sitting in the directory that you started SXEmacs from, or your home directory if that other directory was not writable). Then, go to that directory and execute a command like:

gdb `which sxemacs` core

and then issue the command ‘where’ to get the stack backtrace. You might have to use dbx or some similar debugger in place of gdb. If you don’t have any such debugger available, complain to your system administrator.

It’s possible that a core file didn’t get produced, in which case you’re out of luck. Go complain to your system administrator and tell him not to disable core files by default. Also see Q2.1.15, for tips and techniques for dealing with a debugger.

When making a problem report make sure that:

1. Report all of the information output by SXEmacs during the crash.
2. You mention what OS & Hardware you are running SXEmacs on.
3. What version of SXEmacs you are running. Equivalently, if you are using your own tla-branch of SXEmacs either tell where it is available or include to which degree your version resembles the mainline.
4. What build options you are using.
5. What are the versions of your libc and external libraries you use.
6. If the problem is related to graphics and you are running Unix, we will also need to know what version of the X Window System you are running, and what window manager you are using.
7. If the problem happened on a TTY, please include the terminal type.

Much of the information above is automatically generated by M-x report-sxemacs-bug. Even more, and often useful, information can be generated by redirecting the output of make and make check to a file (,,make-all.out and ,,make-check.out are the default used by build-report), and executing M-x build-rpt.