aboutsummaryrefslogtreecommitdiff
path: root/gdb/doc/gdb.bugs-m4
diff options
context:
space:
mode:
authorK. Richard Pixley <rich@cygnus>1992-12-08 04:59:31 +0000
committerK. Richard Pixley <rich@cygnus>1992-12-08 04:59:31 +0000
commit43bbd567f2d928b2628e508ee9c75a3920e26b4d (patch)
tree21f1ab246e1a3f963e73c3662bc1d44f591349a1 /gdb/doc/gdb.bugs-m4
parenta362ee23634a2f9ce9642eab09592e8ff6ae509b (diff)
downloadgdb-43bbd567f2d928b2628e508ee9c75a3920e26b4d.zip
gdb-43bbd567f2d928b2628e508ee9c75a3920e26b4d.tar.gz
gdb-43bbd567f2d928b2628e508ee9c75a3920e26b4d.tar.bz2
recording file death
Diffstat (limited to 'gdb/doc/gdb.bugs-m4')
-rwxr-xr-xgdb/doc/gdb.bugs-m4221
1 files changed, 0 insertions, 221 deletions
diff --git a/gdb/doc/gdb.bugs-m4 b/gdb/doc/gdb.bugs-m4
index 9647926..e69de29 100755
--- a/gdb/doc/gdb.bugs-m4
+++ b/gdb/doc/gdb.bugs-m4
@@ -1,221 +0,0 @@
-_dnl__ Copyright (c) 1990 1991 Free Software Foundation, Inc.
-_dnl__ This file is part of the source for the GDB manual.
-@c M4 FRAGMENT: $Id$
-@node _GDBN__ Bugs, Renamed Commands, Emacs, Top
-@chapter Reporting Bugs in _GDBN__
-@cindex Bugs in _GDBN__
-@cindex Reporting Bugs in _GDBN__
-
-Your bug reports play an essential role in making _GDBN__ reliable.
-
-Reporting a bug may help you by bringing a solution to your problem, or it
-may not. But in any case the principal function of a bug report is to help
-the entire community by making the next version of _GDBN__ work better. Bug
-reports are your contribution to the maintenance of _GDBN__.
-
-In order for a bug report to serve its purpose, you must include the
-information that enables us to fix the bug.
-
-@menu
-* Bug Criteria:: Have You Found a Bug?
-* Bug Reporting:: How to Report Bugs
-@end menu
-
-@node Bug Criteria, Bug Reporting, _GDBN__ Bugs, _GDBN__ Bugs
-@section Have You Found a Bug?
-@cindex Bug Criteria
-
-If you are not sure whether you have found a bug, here are some guidelines:
-
-@itemize @bullet
-@item
-@cindex Fatal Signal
-@cindex Core Dump
-If the debugger gets a fatal signal, for any input whatever, that is a
-_GDBN__ bug. Reliable debuggers never crash.
-
-@item
-@cindex error on Valid Input
-If _GDBN__ produces an error message for valid input, that is a bug.
-
-@item
-@cindex Invalid Input
-If _GDBN__ does not produce an error message for invalid input,
-that is a bug. However, you should note that your idea of
-``invalid input'' might be our idea of ``an extension'' or ``support
-for traditional practice''.
-
-@item
-If you are an experienced user of debugging tools, your suggestions
-for improvement of _GDBN__ are welcome in any case.
-@end itemize
-
-@node Bug Reporting, , Bug Criteria, _GDBN__ Bugs
-@section How to Report Bugs
-@cindex Bug Reports
-@cindex Compiler Bugs, Reporting
-
-A number of companies and individuals offer support for GNU products.
-If you obtained _GDBN__ from a support organization, we recommend you
-contact that organization first.
-
-Contact information for many support companies and individuals is
-available in the file @file{etc/SERVICE} in the GNU Emacs distribution.
-
-In any event, we also recommend that you send bug reports for _GDBN__ to one
-of these addresses:
-
-@example
-bug-gdb@@prep.ai.mit.edu
-@{ucbvax|mit-eddie|uunet@}!prep.ai.mit.edu!bug-gdb
-@end example
-
-@strong{Do not send bug reports to @samp{info-gdb}, or to
-@samp{help-gdb}, or to any newsgroups.} Most users of _GDBN__ do not want to
-receive bug reports. Those that do, have arranged to receive @samp{bug-gdb}.
-
-The mailing list @samp{bug-gdb} has a newsgroup which serves as a
-repeater. The mailing list and the newsgroup carry exactly the same
-messages. Often people think of posting bug reports to the newsgroup
-instead of mailing them. This appears to work, but it has one problem
-which can be crucial: a newsgroup posting often lacks a mail path
-back to the sender. Thus, if we need to ask for more information, we
-may be unable to reach you. For this reason, it is better to send bug
-reports to the mailing list.
-
-As a last resort, send bug reports on paper to:
-
-@example
-GNU Debugger Bugs
-545 Tech Square
-Cambridge, MA 02139
-@end example
-
-The fundamental principle of reporting bugs usefully is this:
-@strong{report all the facts}. If you are not sure whether to state a
-fact or leave it out, state it!
-
-Often people omit facts because they think they know what causes the
-problem and assume that some details don't matter. Thus, you might
-assume that the name of the variable you use in an example does not matter.
-Well, probably it doesn't, but one cannot be sure. Perhaps the bug is a
-stray memory reference which happens to fetch from the location where that
-name is stored in memory; perhaps, if the name were different, the contents
-of that location would fool the debugger into doing the right thing despite
-the bug. Play it safe and give a specific, complete example. That is the
-easiest thing for you to do, and the most helpful.
-
-Keep in mind that the purpose of a bug report is to enable us to fix
-the bug if it is new to us. It isn't as important what happens if
-the bug is already known. Therefore, always write your bug reports on
-the assumption that the bug has not been reported previously.
-
-Sometimes people give a few sketchy facts and ask, ``Does this ring a
-bell?'' Those bug reports are useless, and we urge everyone to
-@emph{refuse to respond to them} except to chide the sender to report
-bugs properly.
-
-To enable us to fix the bug, you should include all these things:
-
-@itemize @bullet
-@item
-The version of _GDBN__. _GDBN__ announces it if you start with no
-arguments; you can also print it at any time using @code{show version}.
-
-Without this, we won't know whether there is any point in looking for
-the bug in the current version of _GDBN__.
-
-@item
-A complete input script, and all necessary source files, that will
-reproduce the bug.
-
-@item
-What compiler (and its version) was used to compile _GDBN__---e.g.
-``_GCC__-1.37.1''.
-
-@item
-The command arguments you gave the compiler to compile your example and
-observe the bug. For example, did you use @samp{-O}? To guarantee
-you won't omit something important, list them all.
-
-If we were to try to guess the arguments, we would probably guess wrong
-and then we might not encounter the bug.
-
-@item
-The type of machine you are using, and the operating system name and
-version number.
-
-@item
-A description of what behavior you observe that you believe is
-incorrect. For example, ``It gets a fatal signal.''
-
-Of course, if the bug is that _GDBN__ gets a fatal signal, then we will
-certainly notice it. But if the bug is incorrect output, we might not
-notice unless it is glaringly wrong. We are human, after all. You
-might as well not give us a chance to make a mistake.
-
-Even if the problem you experience is a fatal signal, you should still
-say so explicitly. Suppose something strange is going on, such as,
-your copy of _GDBN__ is out of synch, or you have encountered a
-bug in the C library on your system. (This has happened!) Your copy
-might crash and ours would not. If you told us to expect a crash,
-then when ours fails to crash, we would know that the bug was not
-happening for us. If you had not told us to expect a crash, then we
-would not be able to draw any conclusion from our observations.
-
-@item
-If you wish to suggest changes to the _GDBN__ source, send us context
-diffs. If you even discuss something in the _GDBN__ source, refer to
-it by context, not by line number.
-
-The line numbers in our development sources won't match those in your
-sources. Your line numbers would convey no useful information to us.
-
-@end itemize
-
-Here are some things that are not necessary:
-
-@itemize @bullet
-@item
-A description of the envelope of the bug.
-
-Often people who encounter a bug spend a lot of time investigating
-which changes to the input file will make the bug go away and which
-changes will not affect it.
-
-This is often time consuming and not very useful, because the way we
-will find the bug is by running a single example under the debugger
-with breakpoints, not by pure deduction from a series of examples.
-We recommend that you save your time for something else.
-
-Of course, if you can find a simpler example to report @emph{instead}
-of the original one, that is a convenience for us. Errors in the
-output will be easier to spot, running under the debugger will take
-less time, etc.
-
-However, simplification is not vital; if you don't want to do this,
-report the bug anyway and send us the entire test case you used.
-
-@item
-A patch for the bug.
-
-A patch for the bug does help us if it is a good one. But don't omit
-the necessary information, such as the test case, on the assumption that
-a patch is all we need. We might see problems with your patch and decide
-to fix the problem another way, or we might not understand it at all.
-
-Sometimes with a program as complicated as _GDBN__ it is very hard to
-construct an example that will make the program follow a certain path
-through the code. If you don't send us the example, we won't be able
-to construct one, so we won't be able to verify that the bug is fixed.
-
-And if we can't understand what bug you are trying to fix, or why your
-patch should be an improvement, we won't install it. A test case will
-help us to understand.
-
-@item
-A guess about what the bug is or what it depends on.
-
-Such guesses are usually wrong. Even we can't guess right about such
-things without first using the debugger to find the facts.
-@end itemize