comparison etc/DEBUG @ 90370:e3bacb89536a

Revision: [e-mail]/emacs--unicode--0--patch-46 Merge from emacs--devo--0 Patches applied: * emacs--devo--0 (patch 157-163) - Update from CVS - Merge from gnus--rel--5.10 * gnus--rel--5.10 (patch 58-61) - Update from CVS

90369:88810aee3a45

and, assuming that "xtype" says that args[0] is a symbol:

   xsymbol

** Debugging what happens while preloading and dumping Emacs

Type `gdb temacs' and start it with `r -batch -l loadup dump'.

If temacs actually succeeds when running under GDB in this way, do not

** 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.
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.

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

90370:e3bacb89536a

and, assuming that "xtype" says that args[0] is a symbol:

   xsymbol

** 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 isavailable 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 temacs actually succeeds when running under GDB in this way, do not

** 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.
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
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.  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

If you experience problems which seem to be related to non-ASCII
characters, such as \201 characters appearing in the buffer or in your