Debugging GNU Emacs
-Copyright (C) 1985, 2000, 2001, 2002, 2003, 2004,
- 2005 Free Software Foundation, Inc.
- Permission is granted to anyone to make or distribute verbatim copies
- of this document as received, in any medium, provided that the
- copyright notice and permission notice are preserved,
- and that the distributor grants the recipient permission
- for further redistribution as permitted by this notice.
+Copyright (C) 1985, 2000, 2001, 2002, 2003, 2004,
+ 2005, 2006, 2007 Free Software Foundation, Inc.
+See the end of the file for license conditions.
- Permission is granted to distribute modified versions
- of this document, or of portions of it,
- under the above conditions, provided also that they
- carry prominent notices stating who last changed them.
[People who debug Emacs on Windows using native Windows debuggers
should read the Windows-specific section near the end of this
** When you debug Emacs with GDB, you should start it in the directory
where the executable was made. That directory has a .gdbinit file
that defines various "user-defined" commands for debugging Emacs.
+(These commands are described below under "Examining Lisp object
+values" and "Debugging Emacs Redisplay problems".)
** When you are trying to analyze failed assertions, it will be
essential to compile Emacs either completely without optimizations or
Put a breakpoint early in `main', or suspend the Emacs,
to get an opportunity to do the set command.
-When Emacs is running in a terminal, it is useful to use a separate terminal
-for the debug session. This can be done by starting Emacs as usual, then
-attaching to it from gdb with the `attach' command which is explained in the
-node "Attach" of the GDB manual.
+When Emacs is running in a terminal, it is sometimes useful to use a separate
+terminal for the debug session. This can be done by starting Emacs as usual,
+then attaching to it from gdb with the `attach' command which is explained in
+the node "Attach" of the GDB manual.
** Examining Lisp object values.
You can also use `pp value' to print the emacs value directly.
-Note: It is not a good idea to try `pr' or `pp' if you know that Emacs
+To see the current value of a Lisp Variable, use `pv variable'.
+
+Note: It is not a good idea to try `pr', `pp', or `pv' if you know that Emacs
is in deep trouble: its stack smashed (e.g., if it encountered SIGSEGV
due to stack overflow), or crucial data structures, such as `obarray',
corrupted, etc. In such cases, the Emacs subroutine called by `pr'
use `pr'. Instead, use `s' to step out of the system call. Then
Emacs will be between instructions and capable of handling `pr'.
-If you can't use `pr' command, for whatever reason, you can fall back
-on lower-level commands. Use the `xtype' command to print out the
-data type of the last data value. Once you know the data type, use
-the command that corresponds to that type. Here are these commands:
+If you can't use `pr' command, for whatever reason, you can use the
+`xpr' command to print out the data type and value of the last data
+value, For example:
+
+ p it->object
+ xpr
+
+You may also analyze data values using lower-level commands. Use the
+`xtype' command to print out the data type of the last data value.
+Once you know the data type, use the command that corresponds to that
+type. Here are these commands:
xint xptr xwindow xmarker xoverlay xmiscfree xintfwd xboolfwd xobjfwd
xbufobjfwd xkbobjfwd xbuflocal xbuffer xsymbol xstring xvector xframe
(gdb) p frame
$1 = 139854428
- (gdb) xtype
+ (gdb) xpr
Lisp_Vectorlike
PVEC_FRAME
- (gdb) xframe
$2 = (struct frame *) 0x8560258
+ "emacs@localhost"
(gdb) p *$
$3 = {
size = 1073742931,
name = 140615219,
[...]
}
- (gdb) p $3->name
- $4 = 140615219
-Now we can use `pr' to print the name of the frame:
+Now we can use `pr' to print the frame parameters:
+
+ (gdb) pp $->param_alist
+ ((background-mode . light) (display-type . color) [...])
- (gdb) pr
- "emacs@steenrod.math.nwu.edu"
The Emacs C code heavily uses macros defined in lisp.h. So suppose
we want the address of the l-value expression near the bottom of
XVECTOR (this_command_keys)->contents[this_command_key_count++] = key;
-XVECTOR is a macro, and therefore, in general, GDB does not know about it.
-Unless Emacs has been compiled with preprocessor macro info, GDB cannot
-evaluate "p XVECTOR (this_command_keys)" .
+XVECTOR is a macro, so GDB only knows about it if Emacs has been compiled with
+preprocessor macro information. GCC provides this if you specify the options
+`-gdwarf-2' and `-g3'. In this case, GDB can evaluate expressions like
+"p XVECTOR (this_command_keys)".
-However, you can use the xvector command in GDB to get the same
-result. Here is how:
+When this information isn't available, you can use the xvector command in GDB
+to get the same result. Here is how:
(gdb) p this_command_keys
$1 = 1078005760
xsymbol
+** Debugging Emacs Redisplay problems
+
+The src/.gdbinit file defines many useful commands for dumping redisplay
+related data structures in a terse and user-friendly format:
+
+ `ppt' prints value of PT, narrowing, and gap in current buffer.
+ `pit' dumps the current display iterator `it'.
+ `pwin' dumps the current window 'win'.
+ `prow' dumps the current glyph_row `row'.
+ `pg' dumps the current glyph `glyph'.
+ `pgi' dumps the next glyph.
+ `pgrow' dumps all glyphs in current glyph_row `row'.
+ `pcursor' dumps current output_cursor.
+
+The above commands also exist in a version with an `x' suffix which
+takes an object of the relevant type as argument.
+
+** Following longjmp call.
+
+Recent versions of glibc (2.4+?) encrypt stored values for setjmp/longjmp which
+prevents GDB from being able to follow a longjmp call using `next'. To
+disable this protection you need to set the environment variable
+LD_POINTER_GUARD to 0.
+
+** Using GDB in Emacs
+
+Debugging with GDB in Emacs offers some advantages over the command line (See
+the GDB Graphical Interface node of the Emacs manual). There are also some
+features available just for debugging Emacs:
+
+1) The command gud-pp is available on the tool bar (the `pp' icon) and
+ allows the user to print the s-expression of the variable at point,
+ in the GUD buffer.
+
+2) Pressing `p' on a component of a watch expression that is a lisp object
+ in the speedbar prints its s-expression in the GUD buffer.
+
+3) The STOP button on the tool bar is adjusted so that it sends SIGTSTP
+ instead of the usual SIGINT.
+
+4) The command gud-pv has the global binding 'C-x C-a C-v' and prints the
+ value of the lisp variable at point.
+
** Debugging what happens while preloading and dumping Emacs
Type `gdb temacs' and start it with `r -batch -l loadup dump'.
** If you encounter X protocol errors
-Try evaluating (x-synchronize t). That puts Emacs into synchronous
-mode, where each Xlib call checks for errors before it returns. This
-mode is much slower, but when you get an error, you will see exactly
-which call really caused the error.
+The X server normally reports protocol errors asynchronously,
+so you find out about them long after the primitive which caused
+the error has returned.
+
+To get clear information about the cause of an error, try evaluating
+(x-synchronize t). That puts Emacs into synchronous mode, where each
+Xlib call checks for errors before it returns. This 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:
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.
+pointer to that object in the `last_marked' array, which is maintained
+as a circular buffer. 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.
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.
+Use the `last_marked' array and the source to reconstruct the sequence
+that objects were marked. In general, you need to correlate the
+values recorded in the `last_marked' array with the corresponding
+stack frames in the backtrace, beginning with the innermost frame.
+Some subroutines of `mark_object' are invoked recursively, others loop
+over portions of the data structure and mark them as they go. By
+looking at the code of those routines and comparing the frames in the
+backtrace with the values in `last_marked', you will be able to find
+connections between the values in `last_marked'. E.g., when GC finds
+a cons cell, it recursively marks its car and its cdr. Similar things
+happen with properties of symbols, elements of vectors, etc. Use
+these connections to reconstruct the data structure that was being
+marked, paying special attention to the strings and names of symbols
+that you encounter: these strings and symbol names can be used to grep
+the sources to find out what high-level symbols and global variables
+are involved in the crash.
+
+Once you discover the corrupted Lisp object or data structure, grep
+the sources for its uses and try to figure out what could cause the
+corruption. If looking at the sources doesn't help, you could try
+setting a watchpoint on the corrupted data, and see what code modifies
+it in some invalid way. (Obviously, this technique is only useful for
+data that is modified only very rarely.)
+
+It is also useful to look at the corrupted object or data structure in
+a fresh Emacs session and compare its contents with a session that you
+are debugging.
** Debugging problems with non-ASCII characters
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
+crashes will be one of those source lines, but not necessarily the one
that the debugger reports.
Another problematic area with the MS debugger is with variables that
and look at those registers directly, to see the actual current values
of these variables.
+\f
+This file is part of GNU Emacs.
+
+GNU Emacs is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GNU Emacs is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Emacs; see the file COPYING. If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+Boston, MA 02110-1301, USA.
+
+\f
+Local variables:
+mode: outline
+paragraph-separate: "[ \f]*$"
+end:
+
;;; arch-tag: fbf32980-e35d-481f-8e4c-a2eca2586e6b