f78
How to report bugs
You can find contact information for many support companies and individuals in
the file ‘
In any event, we also recommend that you send bug reports for GDB to one of
these addresses:
{ucbvax|mit-eddie|uunet}!prep.ai.mit.edu!bug-gdb
The mailing list ‘
GNU
Free Software Foundation Inc.
59 Temple Place Suite 330
Boston, MA 02111-1307 USA
Often people omit facts because they think they know what causes the problem
and assume that some details do not matter. Thus, you might assume that the name
of the variable you use in an example does not matter. Well, probably it does
not, 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. 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 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 the following things.
The version of GDB. GDB announces it if you start with no arguments; you can
also print it at any time using
Without this, we will not know whether there is any point in looking for the
bug in the current version of GDB.
The type of machine you are using, and the operating system name and version
number.
What compiler (and its version) was used to compile GDB—e.g., “gcc–2.0”.
What compiler (and its version) was used to compile the program you are
debugging—e.g., “gcc–2.0”.
The command arguments you gave the compiler to compile your example and
observe the bug. For example, did you use ‘
If we were to try to guess the arguments, we would probably guess wrong and
then we might not encounter the bug.
A complete input script, and all necessary source files, that will reproduce
the bug.
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 GDB 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. 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 GDB 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.
If you wish to suggest changes to the GDB source, send us context diffs. If
you even discuss something in the GDB source, refer to it by context, not by line
number.
The line numbers in our development sources will not match those in your
sources. Your line numbers would convey no useful information to us.
The following describes some things that are not necessary:
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 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, and so on.
However, simplification is not vital; if you do not want to do this, report
the bug anyway and send us the entire test case you used.
A patch for the bug.
A patch for the bug does help us
412
if it is a good one. But do not 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 GDB it is very hard to construct an
example that will make the program follow a certain path through the code.
If you do not send us the example, we will not be able to construct one, so we
will not be able to verify that the bug is fixed.
And if we cannot understand what bug you are trying to fix, or why your patch
should be an improvement, we will not install it. A test case will help us to
understand.
A guess about what the bug is or what it depends on.
Such guesses are usually wrong.
Even we cannot guess right about such things without first using the debugger
to find the facts.