# HG changeset patch # User Eli Zaretskii # Date 981271758 0 # Node ID 99572fa1c8c3d3b0bac27c4bf4156d5124c44430 # Parent 1cd4a45e9aaefcd64e1cf605fd17ebdfcf30725d Remove the more arcane part of Emacs debug instructions. Replace them with a reference to etc/DEBUG. diff -r 1cd4a45e9aae -r 99572fa1c8c3 man/trouble.texi --- a/man/trouble.texi Sat Feb 03 18:27:42 2001 +0000 +++ b/man/trouble.texi Sun Feb 04 07:29:18 2001 +0000 @@ -718,30 +718,6 @@ For a short listing of Lisp functions running, type the GDB command @code{xbacktrace}. -If you want to examine Lisp function arguments, move up the stack, and -each time you get to a frame for the function @code{Ffuncall}, type -these GDB commands: - -@example -p *args -pr -@end example - -@noindent -To print the first argument that the function received, use these -commands: - -@example -p args[1] -pr -@end example - -@noindent -You can print the other arguments likewise. The argument @code{nargs} -of @code{Ffuncall} says how many arguments @code{Ffuncall} received; -these include the Lisp function itself and the arguments for that -function. - The file @file{.gdbinit} defines several other commands that are useful for examining the data types and contents of Lisp objects. Their names begin with @samp{x}. These commands work at a lower level than @@ -749,32 +725,18 @@ @code{pr} does not, such as when debugging a core dump or when Emacs has had a fatal signal. -@item -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. To find out -which, make the problem happen under GDB and stop Emacs once it is not -responding. (If Emacs is using X directly, you can stop Emacs by typing -@kbd{C-z} at the GDB job.) Then try stepping with @samp{step}. If -Emacs is hung, the @samp{step} command won't return. If it is looping, -@samp{step} will return. - -If this shows Emacs is hung in a system call, stop it again and examine -the arguments of the call. In your bug report, state exactly where in -the source the system call is, and what the arguments are. +@cindex debugging Emacs, tricks and techniques +More detailed advice and other useful techniques for debugging Emacs +are available in the file @file{etc/DEBUG} in the Emacs distribution. +That file also includes instructions for investigating problems +whereby Emacs stops responding (many people assume that Emacs is +``hung'', whereas in fact it might be in an infinite loop). -If Emacs is in an infinite loop, please determine where the loop starts -and ends. The easiest way to do this is to use the GDB command -@samp{finish}. Each time you use it, Emacs resumes execution until it -exits one stack frame. Keep typing @samp{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 @samp{finish} repeatedly again until you get -@emph{back to} that frame. Then use @samp{next} to step through that -frame. By stepping, you will see where the loop starts and ends. Also -please examine the data being used in the loop and try to determine why -the loop does not exit when it should. Include all of this information -in your bug report. +In an installed Emacs, the file @file{etc/DEBUG} is in the same +directory where the Emacs on-line documentation file @file{DOC}, +typically in the @file{/usr/local/share/emacs/@var{version}/etc/} +directory. The directory for your installation is stored in the +variable @code{data-directory}. @end itemize Here are some things that are not necessary in a bug report: