Debugging GNU Emacs
-Copyright (C) 1985, 2000-2015 Free Software Foundation, Inc.
+Copyright (C) 1985, 2000-2016 Free Software Foundation, Inc.
See the end of the file for license conditions.
+** Preliminaries
-[People who debug Emacs on Windows using Microsoft debuggers should
-read the Windows-specific section near the end of this document.]
+This section can be skipped if you are already familiar with building
+Emacs with debug info, configuring and starting GDB, and simple GDB
+debugging techniques.
-** When you debug Emacs with GDB, you should start GDB in the directory
+*** Configuring Emacs for debugging
+
+It is best to configure and build Emacs with special options that will
+make the debugging easier. Here's the configure-time options we
+recommend (they are in addition to any other options you might need,
+such as --prefix):
+
+ CFLAGS='-O0 -g3' ./configure --enable-checking='yes,glyphs' --enable-check-lisp-object-type
+
+The CFLAGS value is important: debugging optimized code can be very
+hard. (If the problem only happens with optimized code, you may need
+to enable optimizations. If that happens, try using -Og first,
+instead of -O2, as the former will disable some optimizations that
+make debugging some code exceptionally hard.)
+
+Modern versions of GCC support more elaborate debug info that is
+available by just using the -g3 compiler switch. Try using -gdwarf-4
+in addition to -g3, and if that fails, try -gdwarf-3. This is
+especially important if you have to debug optimized code. More info
+about this is available below; search for "analyze failed assertions".
+
+The 2 --enable-* switches are optional. They don't have any effect on
+debugging with GDB, but will compile additional code that might catch
+the problem you are debugging much earlier, in the form of assertion
+violation. The --enable-checking option also enables additional
+functionality useful for debugging display problems; see more about
+this below under "Debugging Emacs redisplay problems".
+
+Emacs needs not be installed to be debugged, you can debug the binary
+created in the 'src' directory.
+
+*** Configuring GDB
+
+When you debug Emacs with GDB, you should start GDB in the directory
where the Emacs executable was made (the 'src' directory in the Emacs
source tree). 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".)
+Starting the debugger from Emacs, via the "M-x gdb" command (described
+below), when the current buffer visits one of the Emacs C source files
+will automatically start GDB in the 'src' directory.
+
Some GDB versions by default do not automatically load .gdbinit files
in the directory where you invoke GDB. With those versions of GDB,
you will see a warning when GDB starts, like this:
warning: File ".../src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
-There are several ways to overcome that difficulty, they are all
-described in the node "Auto-loading safe path" in the GDB user
-manual. If nothing else helps, type "source /path/to/.gdbinit RET" at
-the GDB prompt, to unconditionally load the GDB init file.
+The simplest way to fix this is to add the following line to your
+~/.gdbinit file:
+
+ add-auto-load-safe-path /path/to/emacs/src/.gdbinit
+
+There are other ways to overcome that difficulty, they are all
+described in the node "Auto-loading safe path" in the GDB user manual.
+If nothing else helps, type "source /path/to/.gdbinit RET" at the GDB
+prompt, to unconditionally load the GDB init file.
+
+*** Use the Emacs GDB UI front-end
+
+We recommend using the GUI front-end for GDB provided by Emacs. With
+it, you can start GDB by typing "M-x gdb RET". This will suggest the
+file name of the default binary to debug; if the suggested default is
+not the Emacs binary you want to debug, change the file name as
+needed. Alternatively, if you want to attach the debugger to an
+already running Emacs process, change the GDB command shown in the
+minibuffer to say this:
+
+ gdb -i=mi -p PID
+
+where PID is the numerical process ID of the running Emacs process,
+displayed by system utilities such as 'top' or 'ps' on Posix hosts and
+Task Manager on MS-Windows.
+
+Once the debugger starts, open the additional windows provided by the
+GDB UI, by typing "M-x gdb-many-windows RET". (Alternatively, click
+Gud->GDB-MI->Display Other Windows" from the menu bar.) At this
+point, make your frame large enough (or full-screen) such that the
+windows you just opened have enough space to show the content without
+horizontal scrolling.
+
+You can later restore your window configuration with the companion
+command "M-x gdb-restore-windows RET", or by deselecting "Display
+Other Windows" from the menu bar.
+
+*** Setting initial breakpoints
+
+Before you let Emacs run, you should now set breakpoints in the code
+which you want to debug, so that Emacs stops there and lets GDB take
+control. If the code which you want to debug is executed under some
+rare conditions, or only when a certain Emacs command is manually
+invoked, then just set your breakpoint there, let Emacs run, and
+trigger the breakpoint by invoking that command or reproducing those
+rare conditions.
+
+If you are less lucky, and the code in question is run very
+frequently, you will have to find some way of avoiding triggering your
+breakpoint when the conditions for the buggy behavior did not yet
+happen. There's no single recipe for this, you will have to be
+creative and study the code to see what's appropriate. Some useful
+tricks for that:
+
+ . Make your breakpoint conditional on certain buffer or string
+ position. For example:
+
+ (gdb) break foo.c:1234 if PT >= 9876
+
+ . Set a break point in some rarely called function, then create the
+ conditions for the bug, call that rare function, and when GDB gets
+ control, set the breakpoint in the buggy code, knowing that it
+ will now be called when the bug happens.
+
+ . If the bug manifests itself as an error message, set a breakpoint
+ in Fsignal, and when it breaks, look at the backtrace to see what
+ triggers the error.
+
+Some additional techniques are described below under "Getting control
+to the debugger".
+
+You are now ready to start your debugging session.
+
+If you are starting a new Emacs session, type "run", followed by any
+command-line arguments (e.g., "-Q") into the *gud-emacs* buffer and
+press RET.
+
+If you attached the debugger to a running Emacs, type "continue" into
+the *gud-emacs* buffer and press RET.
+
+Many variables you will encounter while debugging are Lisp objects.
+These are displayed as integer values (or structures, if you used the
+"--enable-check-lisp-object-type" option at configure time) that are
+hard to interpret, especially if they represent long lists. You can
+use the 'pp' command to display them in their Lisp form. That command
+displays its output on the standard error stream, which you
+can redirect to a file using "M-x redirect-debugging-output".
+This means that if you attach GDB to a running Emacs that was invoked
+from a desktop icon, chances are you will not see the output at all,
+or it will wind up in an obscure place (check the documentation of
+your desktop environment).
+
+Additional information about displaying Lisp objects can be found
+under "Examining Lisp object values" below.
+
+The rest of this document describes specific useful techniques for
+debugging Emacs; we suggest reading it in its entirety the first time
+you are about to debug Emacs, then look up your specific issues
+whenever you need.
+
+Good luck!
** When you are trying to analyze failed assertions or backtraces, it
is essential to compile Emacs with flags suitable for debugging.
** Getting control to the debugger
-`Fsignal' is a very useful place to put a breakpoint in. All Lisp
+'Fsignal' is a very useful place to put a breakpoint in. All Lisp
errors go through there. If you are only interested in errors that
-would fire the debugger, breaking at `maybe_call_debugger' is useful.
+would fire the debugger, breaking at 'maybe_call_debugger' is useful.
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-z at the
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 `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 'nopass'.
-A technique that can work when `handle SIGINT' does not is to store
+A technique that can work when 'handle SIGINT' does not is to store
the code for some character into the variable stop_character. Thus,
set stop_character = 29
makes Control-] (decimal code 29) the stop character.
Typing Control-] will cause immediate stop. You cannot
use the set command until the inferior process has been started.
-Put a breakpoint early in `main', or suspend the Emacs,
+Put a breakpoint early in 'main', or suspend the Emacs,
to get an opportunity to do the set command.
Another technique for get control to the debugger is to put a
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
+then attaching to it from gdb with the 'attach' command which is explained in
the node "Attach" of the GDB manual.
On MS-Windows, you can start Emacs in its own separate terminal by
** Examining Lisp object values.
When you have a live process to debug, and it has not encountered a
-fatal error, you can use the GDB command `pr'. First print the value
-in the ordinary way, with the `p' command. Then type `pr' with no
+fatal error, you can use the GDB command 'pr'. First print the value
+in the ordinary way, with the 'p' command. Then type 'pr' with no
arguments. This calls a subroutine which uses the Lisp printer.
-You can also use `pp value' to print the emacs value directly.
+You can also use 'pp value' to print the emacs value directly.
-To see the current value of a Lisp Variable, use `pv variable'.
+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
+These commands send their output to stderr; if that is closed or
+redirected to some file you don't know, you won't see their output.
+This is particularly so for Emacs invoked on MS-Windows from the
+desktop shortcut. You can use the command 'redirect-debugging-output'
+to redirect stderr to a file.
+
+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'
+due to stack overflow), or crucial data structures, such as 'obarray',
+corrupted, etc. In such cases, the Emacs subroutine called by 'pr'
might make more damage, like overwrite some data that is important for
debugging the original problem.
-Also, on some systems it is impossible to use `pr' if you stopped
-Emacs while it was inside `select'. This is in fact what happens if
+Also, on some systems it is impossible to use 'pr' if you stopped
+Emacs while it was inside 'select'. This is in fact what happens if
you stop Emacs while it is waiting. In such a situation, don't try to
-use `pr'. Instead, use `s' to step out of the system call. Then
-Emacs will be between instructions and capable of handling `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 use the
-`xpr' command to print out the data type and value of the last data
+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.
+'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:
[...]
}
-Now we can use `pr' to print the frame parameters:
+Now we can use 'pp' to print the frame parameters:
(gdb) pp $->param_alist
((background-mode . light) (display-type . color) [...])
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
-`add_command_key' from keyboard.c:
+'add_command_key' from keyboard.c:
XVECTOR (this_command_keys)->contents[this_command_key_count++] = key;
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-N' (where N is 2 or higher) and `-g3'. In this case, GDB can
+'-gdwarf-N' (where N is 2 or higher) and '-g3'. In this case, GDB can
evaluate expressions like "p XVECTOR (this_command_keys)".
When this information isn't available, you can use the xvector command in GDB
(gdb) p &$
$4 = (int *) 0x411008
-Here's a related example of macros and the GDB `define' command.
-There are many Lisp vectors such as `recent_keys', which contains the
+Here's a related example of macros and the GDB 'define' command.
+There are many Lisp vectors such as 'recent_keys', which contains the
last 300 keystrokes. We can print this Lisp vector
p recent_keys
pr
-But this may be inconvenient, since `recent_keys' is much more verbose
-than `C-h l'. We might want to print only the last 10 elements of
-this vector. `recent_keys' is updated in keyboard.c by the command
+But this may be inconvenient, since 'recent_keys' is much more verbose
+than 'C-h l'. We might want to print only the last 10 elements of
+this vector. 'recent_keys' is updated in keyboard.c by the command
XVECTOR (recent_keys)->contents[recent_keys_index] = c;
-So we define a GDB command `xvector-elts', so the last 10 keystrokes
+So we define a GDB command 'xvector-elts', so the last 10 keystrokes
are printed by
xvector-elts recent_keys recent_keys_index 10
document xvector-elts
Prints a range of elements of a Lisp vector.
xvector-elts v n i
- prints `i' elements of the vector `v' ending at the index `n'.
+ prints 'i' elements of the vector 'v' ending at the index 'n'.
end
** Getting Lisp-level backtrace information within GDB
-The most convenient way is to use the `xbacktrace' command. This
+The most convenient way is to use the 'xbacktrace' command. This
shows the names of the Lisp functions that are currently active.
-If that doesn't work (e.g., because the `backtrace_list' structure is
+If that doesn't work (e.g., because the 'backtrace_list' structure is
corrupted), type "bt" at the GDB prompt, to produce the C-level
backtrace, and look for stack frames that call Ffuncall. Select them
one by one in GDB, by typing "up N", where N is the appropriate number
optimizations might be involved if "M-x redraw-display RET", or even just
typing "M-x", causes Emacs to correct the bad display.) Since the cursor
blinking feature triggers periodic redisplay cycles, we recommend disabling
-`blink-cursor-mode' before invoking `trace-redisplay', so that you have less
+'blink-cursor-mode' before invoking 'trace-redisplay', so that you have less
clutter in the trace. You can also have up to 30 last trace messages dumped to
-standard error by invoking the `dump-redisplay-history' command.
+standard error by invoking the 'dump-redisplay-history' command.
To find the code paths which were taken by the display engine, search xdisp.c
for the trace messages you see.
-The command `dump-glyph-matrix' is useful for producing on standard error
+The command 'dump-glyph-matrix' is useful for producing on standard error
stream a full dump of the selected window's glyph matrix. See the function's
doc string for more details. If you are debugging redisplay issues in
-text-mode frames, you may find the command `dump-frame-glyph-matrix' useful.
+text-mode frames, you may find the command 'dump-frame-glyph-matrix' useful.
-Other commands useful for debugging redisplay are `dump-glyph-row' and
-`dump-tool-bar-row'.
+Other commands useful for debugging redisplay are 'dump-glyph-row' and
+'dump-tool-bar-row'.
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':
+whose pointer is in 'w':
(gdb) p dump_glyph_matrix (w->current_matrix, 2)
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 `eassert'
+code which tests these assertions, look for calls to the 'eassert'
macros.) Any assertion that is reported to fail should be investigated.
When you debug display problems running emacs under X, you can use
-the `ff' command to flush all pending display updates to the screen.
+the 'ff' command to flush all pending display updates to the screen.
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.
+ '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. For example, `pgrowx' dumps all
-glyphs in its argument, which must be of type `struct glyph_row'.
+The above commands also exist in a version with an 'x' suffix which takes an
+object of the relevant type as argument. For example, 'pgrowx' dumps all
+glyphs in its argument, which must be of type 'struct glyph_row'.
Since redisplay is performed by Emacs very frequently, you need to place your
breakpoints cleverly to avoid hitting them all the time, when the issue you are
debugging did not (yet) happen. Here are some useful techniques for that:
- . Put a breakpoint at `Fredraw_display' before running Emacs. Then do
+ . Put a breakpoint at 'Fredraw_display' before running Emacs. Then do
whatever is required to reproduce the bad display, and invoke "M-x
redraw-display". The debugger will kick in, and you can set or enable
breakpoints in strategic places, knowing that the bad display will be
redrawn from scratch.
. For debugging incorrect cursor position, a good place to put a breakpoint is
- in `set_cursor_from_row'. The first time this function is called as part of
- `redraw-display', Emacs is redrawing the minibuffer window, which is usually
+ in 'set_cursor_from_row'. The first time this function is called as part of
+ 'redraw-display', Emacs is redrawing the minibuffer window, which is usually
not what you want; type "continue" to get to the call you want. In general,
- always make sure `set_cursor_from_row' is called for the right window and
+ always make sure 'set_cursor_from_row' is called for the right window and
buffer by examining the value of w->contents: it should be the buffer whose
display you are debugging.
- . `set_cursor_from_row' is also a good place to look at the contents of a
- screen line (a.k.a. "glyph row"), by means of the `pgrow' GDB command. Of
+ . 'set_cursor_from_row' is also a good place to look at the contents of a
+ screen line (a.k.a. "glyph row"), by means of the 'pgrow' GDB command. Of
course, you need first to make sure the cursor is on the screen line which
- you want to investigate. If you have set a breakpoint in `Fredraw_display',
- as advised above, move cursor to that line before invoking `redraw-display'.
+ you want to investigate. If you have set a breakpoint in 'Fredraw_display',
+ as advised above, move cursor to that line before invoking 'redraw-display'.
. If the problem happens only at some specific buffer position or for some
specific rarely-used character, you can make your breakpoints conditional on
. You can also make the breakpoints conditional on what object is being used
for producing glyphs for display. The it->method member has the value
GET_FROM_BUFFER for displaying buffer contents, GET_FROM_STRING for
- displaying a Lisp string (e.g., a `display' property or an overlay string),
- GET_FROM_IMAGE for displaying an image, etc. See `enum it_method' in
+ displaying a Lisp string (e.g., a 'display' property or an overlay string),
+ GET_FROM_IMAGE for displaying an image, etc. See 'enum it_method' in
dispextern.h for the full list of values.
** 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
+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.
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
+1) The command gud-print is available on the tool bar (the 'p' 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
+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.
+3) The STOP button on the tool bar and the Signals->STOP menu-bar menu
+ item are adjusted so that they send 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
-Debugging `temacs' is useful when you want to establish whether a
-problem happens in an undumped Emacs. To run `temacs' under a
-debugger, type "gdb temacs", then start it with `r -batch -l loadup'.
+Debugging 'temacs' is useful when you want to establish whether a
+problem happens in an undumped Emacs. To run 'temacs' under a
+debugger, type "gdb temacs", then start it with 'r -batch -l loadup'.
-If you need to debug what happens during dumping, start it with `r -batch -l
+If you need to debug what happens during dumping, start it with 'r -batch -l
loadup dump' instead. For debugging the bootstrap dumping, use "loadup
bootstrap" instead of "loadup dump".
emacs -xrm "emacs.synchronous: true"
-Setting a breakpoint in the function `x_error_quitter' and looking at
+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.
- 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'.
+ 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
+ - 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
+ 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
+ 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
+ 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)
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
+ 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
** 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.
+Don't assume Emacs is 'hung'--it may instead be in an infinite loop.
To find out which, make the problem happen under GDB and stop Emacs
once it is not responding. (If Emacs is using X Windows directly, you
can stop Emacs by typing C-z at the GDB job. On MS-Windows, run Emacs
whatever Emacs is doing and let you perform the steps described
below.)
-Then try stepping with `step'. If Emacs is hung, the `step' command
-won't return. If it is looping, `step' will return.
+Then try stepping with 'step'. If Emacs is hung, the 'step' command
+won't return. If it is looping, 'step' will return.
If this shows Emacs is hung in a system call, stop it again and
examine the arguments of the call. If you report the bug, it is very
If Emacs is in an infinite loop, try to determine where the loop
starts and ends. The easiest way to do this is to use the GDB command
-`finish'. Each time you use it, Emacs resumes execution until it
-exits one stack frame. Keep typing `finish' until it doesn't
+'finish'. Each time you use it, Emacs resumes execution until it
+exits one stack frame. Keep typing 'finish' until it doesn't
return--that means the infinite loop is in the stack frame which you
just tried to finish.
-Stop Emacs again, and use `finish' repeatedly again until you get back
-to that frame. Then use `next' to step through that frame. By
+Stop Emacs again, and use 'finish' repeatedly again until you get back
+to that frame. Then use 'next' to step through that frame. By
stepping, you will see where the loop starts and ends. Also, examine
the data being used in the loop and try to determine why the loop does
not exit when it should.
On GNU and Unix systems, you can also trying sending Emacs SIGUSR2,
-which, if `debug-on-event' has its default value, will cause Emacs to
+which, if 'debug-on-event' has its default value, will cause Emacs to
attempt to break it out of its current loop and into the Lisp
-debugger. This feature is useful when a C-level debugger is not
-conveniently available.
+debugger. (See the node "Debugging" in the ELisp manual for the
+details about the Lisp debugger.) This feature is useful when a
+C-level debugger is not conveniently available.
** If certain operations in Emacs are slower than they used to be, here
is some advice for how to find out why.
17:i
:r -l loadup (or whatever)
-It is necessary to refer to the file `nmout' to convert
+It is necessary to refer to the file 'nmout' to convert
numeric addresses into symbols and vice versa.
It is useful to be running under a window system.
The dribble file contains all characters read by Emacs from the
terminal, and the termscript file contains all characters it sent to
-the terminal. The use of the directory `~/' prevents interference
+the terminal. The use of the directory '~/' prevents interference
with any other user.
If you have irreproducible display problems, put those two expressions
another Emacs without clobbering those files, and use it to examine them.
An easy way to see if too much text is being redrawn on a terminal is to
-evaluate `(setq inverse-video t)' before you try the operation you think
+evaluate '(setq inverse-video t)' before you try the operation you think
will cause too much redrawing. This doesn't refresh the screen, so only
newly drawn text is in inverse video.
If you encounter bugs whereby Emacs built with LessTif grabs all mouse
and keyboard events, or LessTif menus behave weirdly, it might be
-helpful to set the `DEBUGSOURCES' and `DEBUG_FILE' environment
+helpful to set the 'DEBUGSOURCES' and 'DEBUG_FILE' environment
variables, so that one can see what LessTif was doing at this point.
For instance
emacs &
causes LessTif to print traces from the three named source files to a
-file in `/usr/tmp' (that file can get pretty large). The above should
+file in '/usr/tmp' (that file can get pretty large). The above should
be typed at the shell prompt before invoking Emacs, as shown by the
last line above.
** Debugging problems which happen in GC
-The array `last_marked' (defined on alloc.c) can be used to display up
+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, 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
+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
+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
+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
+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
+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
+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
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
+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
directed to the xterm window you opened above.
Similar arrangement is possible on a character terminal by using the
-`screen' package.
+'screen' package.
On MS-Windows, you can start Emacs in its own separate terminal by
setting the new-console option before running Emacs under GDB:
- cd ..; src/temacs
-(Note that this runs `temacs' instead of the usual `emacs' executable.
+(Note that this runs 'temacs' instead of the usual 'emacs' executable.
This avoids problems with dumping Emacs mentioned above.)
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'
+these data structures on the respective headers to remove the ':N'
bitfield definitions (which will cause each such field to use a full
int).
might also find those commands useful for displaying the list of
buffers in human-readable format from within the debugger.
-** 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,
-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,
-Start debug). Emacs will start and the debugger will take control as
-soon as a breakpoint is hit.
-
-You can also attach the debugger to an already running Emacs process.
-To do this, start up the Microsoft Developer studio and select Build,
-Start debug, Attach to process. Choose the Emacs process from the
-list. Send a break to the running process (Debug, Break) and you will
-find that execution is halted somewhere in user32.dll. Open the stack
-trace window and go up the stack to w32_msg_pump. Now you can set
-breakpoints in Emacs (Edit, Breakpoints). Continue the running Emacs
-process (Debug, Step out) and control will return to Emacs, until a
-breakpoint is hit.
-
-To examine the contents of a Lisp variable, you can use the function
-'debug_print'. Right-click on a variable, select QuickWatch (it has
-an eyeglass symbol on its button in the toolbar), and in the text
-field at the top of the window, place 'debug_print(' and ')' around
-the expression. Press 'Recalculate' and the output is sent to stderr,
-and to the debugger via the OutputDebugString routine. The output
-sent to stderr should be displayed in the console window that was
-opened when the emacs.exe executable was started. The output sent to
-the debugger should be displayed in the 'Debug' pane in the Output
-window. If Emacs was started from the debugger, a console window was
-opened at Emacs' startup; this console window also shows the output of
-'debug_print'.
-
-For example, start and run Emacs in the debugger until it is waiting
-for user input. Then click on the `Break' button in the debugger to
-halt execution. Emacs should halt in `ZwUserGetMessage' waiting for
-an input event. Use the `Call Stack' window to select the procedure
-`w32_msp_pump' up the call stack (see below for why you have to do
-this). Open the QuickWatch window and enter
-"debug_print(Vexec_path)". Evaluating this expression will then print
-out the contents of the Lisp variable `exec-path'.
-
-If QuickWatch reports that the symbol is unknown, then check the call
-stack in the `Call Stack' window. If the selected frame in the call
-stack is not an Emacs procedure, then the debugger won't recognize
-Emacs symbols. Instead, select a frame that is inside an Emacs
-procedure and try using `debug_print' again.
-
-If QuickWatch invokes debug_print but nothing happens, then check the
-thread that is selected in the debugger. If the selected thread is
-not the last thread to run (the "current" thread), then it cannot be
-used to execute debug_print. Use the Debug menu to select the current
-thread and try using debug_print again. Note that the debugger halts
-execution (e.g., due to a breakpoint) in the context of the current
-thread, so this should only be a problem if you've explicitly switched
-threads.
-
-It is also possible to keep appropriately masked and typecast Lisp
-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 necessarily 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.
-
\f
This file is part of GNU Emacs.