should read the Windows-specific section near the end of this
document.]
-It is a good idea to run Emacs under GDB (or some other suitable
+** When you debug Emacs with GDB, you should start it in the directory
+where you built Emacs. That directory has a .gdbinit file that defines
+various "user-defined" commands for debugging Emacs.
+
+** It is a good idea to run Emacs under GDB (or some other suitable
debugger) *all the time*. Then, when Emacs crashes, you will be able
to debug the live process, not just a core dump. (This is especially
important on systems which don't support core files, and instead print
just the registers and some stack addresses.)
-If Emacs hangs, or seems to be stuck in some infinite loop, typing
+** If Emacs hangs, or seems to be stuck in some infinite loop, typing
"kill -TSTP PID", where PID is the Emacs process ID, will cause GDB to
kick in, provided that you run under GDB.
All Lisp errors go through there.
It is useful, when debugging, to have a guaranteed way to return to
-the debugger at any time. When using X, this is easy: type C-c at the
+the debugger at any time. When using X, this is easy: type C-z at the
window where Emacs is running under GDB, and it will stop Emacs just
as it would stop any ordinary program. When Emacs is running in a
terminal, things are not so easy.
(C-g in Emacs) to be passed to Emacs and not give control back to GDB.
On modern POSIX systems, you can override that with this command:
- handle int stop nopass
+ handle SIGINT stop nopass
After this `handle' command, SIGINT will return control to GDB. If
you want the C-g to cause a QUIT within Emacs as well, omit the
mode is much slower, but when you get an error, you will see exactly
which call really caused the error.
+You can start Emacs in a synchronous mode by invoking it with the -xrm
+option, like this:
+
+ emacs -xrm "emacs.synchronous: true"
+
+Setting a breakpoint in the function `x_error_quitter' and looking at
+the backtrace when Emacs stops inside that function will show what
+code causes the X protocol errors.
+
+Some bugs related to the X protocol disappear when Emacs runs in a
+synchronous mode. To track down those bugs, we suggest the following
+procedure:
+
+ - Run Emacs under a debugger and put a breakpoint inside the
+ primitive function which, when called from Lisp, triggers the X
+ protocol errors. For example, if the errors happen when you
+ delete a frame, put a breakpoint inside `Fdelete_frame'.
+
+ - When the breakpoint breaks, step through the code, looking for
+ calls to X functions (the ones whose names begin with "X" or
+ "Xt" or "Xm").
+
+ - Insert calls to `XSync' before and after each call to the X
+ functions, like this:
+
+ XSync (f->output_data.x->display_info->display, 0);
+
+ where `f' is the pointer to the `struct frame' of the selected
+ frame, normally available via XFRAME (selected_frame). (Most
+ functions which call X already have some variable that holds the
+ pointer to the frame, perhaps called `f' or `sf', so you shouldn't
+ need to compute it.)
+
+ If your debugger can call functions in the program being debugged,
+ you should be able to issue the calls to `XSync' without recompiling
+ Emacs. For example, with GDB, just type:
+
+ call XSync (f->output_data.x->display_info->display, 0)
+
+ before and immediately after the suspect X calls. If your
+ debugger does not support this, you will need to add these pairs
+ of calls in the source and rebuild Emacs.
+
+ Either way, systematically step through the code and issue these
+ calls until you find the first X function called by Emacs after
+ which a call to `XSync' winds up in the function
+ `x_error_quitter'. The first X function call for which this
+ happens is the one that generated the X protocol error.
+
+ - You should now look around this offending X call and try to figure
+ out what is wrong with it.
+
** If the symptom of the bug is that Emacs fails to respond
Don't assume Emacs is `hung'--it may instead be in an infinite loop.
will cause too much redrawing. This doesn't refresh the screen, so only
newly drawn text is in inverse video.
+The Emacs display code includes special debugging code, but it is
+normally disabled. You can enable it by building Emacs with the
+pre-processing symbol GLYPH_DEBUG defined. Here's one easy way,
+suitable for Unix and GNU systems, to build such a debugging version:
+
+ MYCPPFLAGS='-DGLYPH_DEBUG=1' make
+
+Building Emacs like that activates many assertions which scrutinize
+display code operation more than Emacs does normally. (To see the
+code which tests these assertions, look for calls to the `xassert'
+macros.) Any assertion that is reported to fail should be
+investigated.
+
+Building with GLYPH_DEBUG defined also defines several helper
+functions which can help debugging display code. One such function is
+`dump_glyph_matrix'. If you run Emacs under GDB, you can print the
+contents of any glyph matrix by just calling that function with the
+matrix as its argument. For example, the following command will print
+the contents of the current matrix of the window whose pointer is in
+`w':
+
+ (gdb) p dump_glyph_matrix (w->current_matrix, 2)
+
+(The second argument 2 tells dump_glyph_matrix to print the glyphs in
+a long form.) You can dump the selected window's current glyph matrix
+interactively with "M-x dump-glyph-matrix RET"; see the documentation
+of this function for more details.
+
+Several more functions for debugging display code are available in
+Emacs compiled with GLYPH_DEBUG defined; type "C-h f dump- TAB" and
+"C-h f trace- TAB" to see the full list.
+
** Debugging LessTif
variables, so that one can see what LessTif was doing at this point.
For instance
- export DEBUGSOURCES="RowColumn.c MenuShell.c MenuUtil.c"
+ export DEBUGSOURCES="RowColumn.c:MenuShell.c:MenuUtil.c"
export DEBUG_FILE=/usr/tmp/LESSTIF_TRACE
emacs &
the machine where you started GDB and use the debugger from there.
-** Running Emacs with Purify
+** Debugging problems which happen in GC
-Some people who are willing to use non-free software use Purify. We
-can't ethically ask you to you become a Purify user; but if you have
-it, and you test Emacs with it, we will not refuse to look at the
-results you find.
+The array `last_marked' (defined on alloc.c) can be used to display up
+to 500 last objects marked by the garbage collection process.
+Whenever the garbage collector marks a Lisp object, it records the
+pointer to that object in the `last_marked' array. The variable
+`last_marked_index' holds the index into the `last_marked' array one
+place beyond where the pointer to the very last marked object is
+stored.
-Emacs compiled with Purify won't run without some hacking. Here are
-some of the changes you might find necessary (SYSTEM-NAME and
-MACHINE-NAME are the names of your OS- and CPU-specific headers in the
-subdirectories of `src'):
+The single most important goal in debugging GC problems is to find the
+Lisp data structure that got corrupted. This is not easy since GC
+changes the tag bits and relocates strings which make it hard to look
+at Lisp objects with commands such as `pr'. It is sometimes necessary
+to convert Lisp_Object variables into pointers to C struct's manually.
+Use the `last_marked' array and the source to reconstruct the sequence
+that objects were marked.
+
+Once you discover the corrupted Lisp object or data structure, it is
+useful to look at it in a fresh Emacs session and compare its contents
+with a session that you are debugging.
+
+** Debugging problems with non-ASCII characters
+
+If you experience problems which seem to be related to non-ASCII
+characters, such as \201 characters appearing in the buffer or in your
+files, set the variable byte-debug-flag to t. This causes Emacs to do
+some extra checks, such as look for broken relations between byte and
+character positions in buffers and strings; the resulting diagnostics
+might pinpoint the cause of the problem.
+
+** Debugging the TTY (non-windowed) version
+
+The most convenient method of debugging the character-terminal display
+is to do that on a window system such as X. Begin by starting an
+xterm window, then type these commands inside that window:
+
+ $ tty
+ $ echo $TERM
+
+Let's say these commands print "/dev/ttyp4" and "xterm", respectively.
+
+Now start Emacs (the normal, windowed-display session, i.e. without
+the `-nw' option), and invoke "M-x gdb RET emacs RET" from there. Now
+type these commands at GDB's prompt:
+
+ (gdb) set args -nw -t /dev/ttyp4
+ (gdb) set environment TERM xterm
+ (gdb) run
+
+The debugged Emacs should now start in no-window mode with its display
+directed to the xterm window you opened above.
+
+Similar arrangement is possible on a character terminal by using the
+`screen' package.
+
+** Running Emacs built with malloc debugging packages
+
+If Emacs exhibits bugs that seem to be related to use of memory
+allocated off the heap, it might be useful to link Emacs with a
+special debugging library, such as Electric Fence (a.k.a. efence) or
+GNU Checker, which helps find such problems.
+
+Emacs compiled with such packages might not run without some hacking,
+because Emacs replaces the system's memory allocation functions with
+its own versions, and because the dumping process might be
+incompatible with the way these packages use to track allocated
+memory. Here are some of the changes you might find necessary
+(SYSTEM-NAME and MACHINE-NAME are the names of your OS- and
+CPU-specific headers in the subdirectories of `src'):
- In src/s/SYSTEM-NAME.h add "#define SYSTEM_MALLOC".
"#define CANNOT_UNEXEC".
- Configure with a different --prefix= option. If you use GCC,
- version 2.7.2 is preferred, as Purify works a lot better with it
- than with 2.95 or later versions.
+ version 2.7.2 is preferred, as some malloc debugging packages
+ work a lot better with it than with 2.95 or later versions.
- - Type "make" then "make -k install". You might need to run
- "make -k install twice.
+ - Type "make" then "make -k install".
- - cd src; purify -chain-length=40 gcc <link command line for temacs>
+ - If required, invoke the package-specific command to prepare
+ src/temacs for execution.
- cd ..; src/temacs
-Note that Purify might print lots of false alarms for bitfields used
-by Emacs in some data structures. If you want to get rid of the false
-alarms, you will have to hack the definitions of these data structures
-on the respective headers to remove the ":N" bitfield definitions
-(which will cause each such field to use a full int).
+(Note that this runs `temacs' instead of the usual `emacs' executable.
+This avoids problems with dumping Emacs mentioned above.)
-** Debugging problems which happen in GC
-
-The array `last_marked' (defined on alloc.c) can be used to display
-up to 500 last objects marked by the garbage collection process. The
-variable `last_marked_index' holds the index into the `last_marked'
-array one place beyond where the very last marked object is stored.
-
-The single most important goal in debugging GC problems is to find the
-Lisp data structure that got corrupted. This is not easy since GC
-changes the tag bits and relocates strings which make it hard to look
-at Lisp objects with commands such as `pr'. It is sometimes necessary
-to convert Lisp_Object variables into pointers to C struct's manually.
-Use the `last_marked' array and the source to reconstruct the sequence
-that objects were marked.
-
-Once you discover the corrupted Lisp object or data structure, it is
-useful to look at it in a fresh session and compare its contents with
-a session that you are debugging.
+Some malloc debugging libraries might print lots of false alarms for
+bitfields used by Emacs in some data structures. If you want to get
+rid of the false alarms, you will have to hack the definitions of
+these data structures on the respective headers to remove the `:N'
+bitfield definitions (which will cause each such field to use a full
+int).
** Some suggestions for debugging on MS Windows:
(written by Marc Fleischeuers, Geoff Voelker and Andrew Innes)
To debug Emacs with Microsoft Visual C++, you either start emacs from
-the debugger or attach the debugger to a running emacs process. To
-start emacs from the debugger, you can use the file bin/debug.bat. The
-Microsoft Developer studio will start and under Project, Settings,
+the debugger or attach the debugger to a running emacs process.
+
+To start emacs from the debugger, you can use the file bin/debug.bat.
+The Microsoft Developer studio will start and under Project, Settings,
Debug, General you can set the command-line arguments and Emacs's
startup directory. Set breakpoints (Edit, Breakpoints) at Fsignal and
other functions that you want to examine. Run the program (Build,
symbols in the Watch window, this is more convenient when steeping
though the code. For instance, on entering apply_lambda, you can
watch (struct Lisp_Symbol *) (0xfffffff & args[0]).
+
+Optimizations often confuse the MS debugger. For example, the
+debugger will sometimes report wrong line numbers, e.g., when it
+prints the backtrace for a crash. It is usually best to look at the
+disassembly to determine exactly what code is being run--the
+disassembly will probably show several source lines followed by a
+block of assembler for those lines. The actual point where Emacs
+crashes will be one of those source lines, but not neccesarily the one
+that the debugger reports.
+
+Another problematic area with the MS debugger is with variables that
+are stored in registers: it will sometimes display wrong values for
+those variables. Usually you will not be able to see any value for a
+register variable, but if it is only being stored in a register
+temporarily, you will see an old value for it. Again, you need to
+look at the disassembly to determine which registers are being used,
+and look at those registers directly, to see the actual current values
+of these variables.
HCoop / bpt / emacs.git / blobdiff