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.
** 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:
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
+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.)
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
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 2, or (at your option)
+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,