
288
Chapter 28. Reporting Bugs in gdb
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. It may be that the bug has
been reported previously, but neither you nor we can know that unless your bug report is complete
and self-contained.
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 these things:
•
The version of gdb. gdb announces it if you start with no arguments; you can also print it at any
time using
show version
.
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.8.1".
•
What compiler (and its version) was used to compile the program you are debugging--e.g. "gcc-
2.8.1", or "HP92453-01 A.10.32.03 HP C Compiler". For GCC, you can say
gcc -version
to get
this information; for other compilers, see the documentation for those compilers.
•
The command arguments you gave the compiler to compile your example and observe the bug. For
example, did you use
-O
? To guarantee you will not omit something important, list them all. A copy
of the Makefile (or the output from make) is sufficient.
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 some-
thing 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.
Here are 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.
Summary of Contents for ENTERPRISE LINUX 3 - SECURITY GUIDE
Page 1: ...Red Hat Enterprise Linux 3 Debugging with gdb ...
Page 12: ...2 Chapter 1 Debugging with gdb ...
Page 28: ...18 Chapter 4 Getting In and Out of gdb ...
Page 34: ...24 Chapter 5 gdb Commands ...
Page 44: ...34 Chapter 6 Running Programs Under gdb ...
Page 68: ...58 Chapter 8 Examining the Stack ...
Page 98: ...88 Chapter 10 Examining Data ...
Page 112: ...102 Chapter 12 Tracepoints ...
Page 118: ...108 Chapter 13 Debugging Programs That Use Overlays ...
Page 138: ...128 Chapter 14 Using gdb with Different Languages ...
Page 144: ...134 Chapter 15 Examining the Symbol Table ...
Page 170: ...160 Chapter 19 Debugging remote programs ...
Page 198: ...188 Chapter 21 Controlling gdb ...
Page 204: ...194 Chapter 22 Canned Sequences of Commands ...
Page 206: ...196 Chapter 23 Command Interpreters ...
Page 216: ...206 Chapter 25 Using gdb under gnu Emacs ...
Page 296: ...286 Chapter 27 gdb Annotations ...
Page 300: ...290 Chapter 28 Reporting Bugs in gdb ...
Page 322: ...312 Chapter 30 Using History Interactively ...
Page 362: ...352 Appendix D gdb Remote Serial Protocol ...
Page 380: ...370 Appendix F GNU GENERAL PUBLIC LICENSE ...
Page 386: ...376 Appendix G GNU Free Documentation License ...
Page 410: ......