Debugging GNU Emacs
Copyright (c) 1985 Richard M. Stallman.

   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.

   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.

I have included in the distribution a version of
dbx (for the Vax) which can debug GNU Emacs.
The dbx that I found installed originally has
several serious bugs that prevent it from loading
GNU Emacs and cause GNU Emacs to malfunction.

This debugger is the file  tdbx  in directory ../dbx.
It has the same commands that dbx standardly has.
(You may have to run  make  in that directory to create tdbx.)

The file .dbxinit in ../src defines some useful aliases;
it also sets up signal handling in a way that permits
GNU Emacs to work properly.

Some problems remain in this version of dbx.  For example, the only
useful way to print a Lisp_Object is in hex.  The only way to do this
is &variable/X.  The top two digits are the data type (with the mark
bit in the sign bit during garbage collection) and the remaining six
digits are the value or pointer.

The `where' command (abbreviated `w') tends to get confused
and print infinite garbage past the end of the real contents
of the stack.  Be prepared to stop it with Control-c.

The `stop in' command tends to get into an infinite loop.
If this happens, just type Control-c.  You will find that
the stop has been established properly.

If you stop a looping dbx command with Control-c, it signals
both dbx and the debugged Emacs.  As a result, the next time
you continue or step Emacs, it will stop immediately and say
"interrupt".  You must continue or step it again.
I tried to fix this, by making the debugged process run in
a different process group, but could not get it to work.


`Fsignal' is a very useful place to stop in.
All Lisp errors go through there.

It is useful, when debugging, to have a guaranteed way
to return to the debugger at any time.  If you are using
interrupt-drived input, which is the default, then Emacs is using
RAW mode and the only way you can do it is to store
the code for some character into the variable stop_character:

    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,
to get an opportunity to do the set command.

If you are using cbreak input (see the Lisp function set-input-mode),
then typing Control-g will cause a SIGINT, which will return control
to dbx immediately unless you have done

    ignore 3


You will note that most of GNU Emacs is written to avoid
declaring a local variable in an inner block, even in
cases where using one would be the cleanest thing to do.
This is because dbx cannot access any of the variables
in a function which has even one variable defined in an
inner block.  A few functions in GNU Emacs do have variables
in inner blocks, only because I wrote them before realizing
that dbx had this problem and never rewrote them to avoid it.


dbx has many other deficiencies.  If I find that I can really
use it as part of GNU, I will fix them.  If I will have to
write another debugger, fixing dbx further is useless to me.


** Debugging on a Sun.

On Sun 68000 systems, I found that no debugger could load
Emacs with a symbol table.  However, I was able to debug
by doing

    nm -n temacs > nmout
    strip temacs
    adb temacs
    0xd:i
    0xe:i
    14:i
    17:i
    :r -l loadup   (or whatever)

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 the window system.
Then, if Emacs becomes hopelessly wedged, you can create
another window to do kill -9 in.  kill -ILL is often
useful too, since that may make Emacs dump core or return
to adb.

** Debugging incorrect screen updating.

To debug Emacs problems that update the screen wrong, it is useful
to have a record of what input you typed and what Emacs sent to the
screen.  To make these records, do

(open-dribble-file "~/.dribble")
(open-termscript "~/.termscript")

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
with any other user.

If you have unreproduceable display problems, put those two expressions
in your ~/.emacs file.  When the problem happens, exit the Emacs that
you were running, kill it, and rename the two files.  Then you can start
another Emacs without clobbering those files, and look at them in it.