]> code.delx.au - gnu-emacs/blobdiff - etc/DEBUG
(viperCard.ps, calccard.ps refcard.ps)
[gnu-emacs] / etc / DEBUG
index 090947d57b5fcc55cab4ecf1dcbb5cc8cb4b27ee..ea4e14866ca8e29c2e2a27bfab8ccbed7f6ce562 100644 (file)
--- a/etc/DEBUG
+++ b/etc/DEBUG
@@ -1,17 +1,9 @@
 Debugging GNU Emacs
-Copyright (C) 1985, 2000, 2001, 2002, 2003, 2004,
-   2005, 2006 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
@@ -20,6 +12,8 @@ document.]
 ** 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
@@ -270,15 +264,22 @@ related data structures in a terse and user-friendly format:
 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 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.
+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.
@@ -305,10 +306,15 @@ debugger, type "gdb temacs", then start it with `r -batch -l loadup'.
 
 ** 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:
@@ -561,7 +567,7 @@ 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
+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.)
@@ -725,7 +731,7 @@ 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 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
@@ -737,4 +743,28 @@ 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.
+
+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)
+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