Debugging with GDB Manual HP WDB v6.3 (5900-2180, August 2012)

22 Reporting Bugs in GDB
Your bug reports play an essential role in making GDB 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 GDB work better. Bug reports are your contribution to the maintenance of GDB.
In order for a bug report to serve its purpose, you must include the information that enables us to
x the bug.
22.1 Have you found a bug?
If you are not sure whether you have found a bug, here are some guidelines:
• If the debugger gets a fatal signal, for any input whatever, that is a GDB bug. Reliable
debuggers never crash.
• If GDB produces an error message for valid input, that is a bug. (Note that if you're cross
debugging, the problem may also be somewhere in the connection to the target.)
• If GDB 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".
• If you are an experienced user of debugging tools, your suggestions for improvement of GDB
are welcome in any case.
22.2 How to report bugs
If you obtained GDB (Hewlett-Packard Wildebeest (based on GDB 5.0-hpwdb- 20000516)) as
part of your HP ANSI C, HP ANSI C++, or HP Fortran compiler kit, report problems to your HP
Support Representative.
If you obtained GDB (Hewlett-Packard Wildebeest (based on GDB 5.0-hpwdb- 20000516)) from
the Hewlett-Packard Web site, report problems to your HP Support Representative. Support is
covered under the support contract for your HP compiler.
The fundamental principle of reporting bugs usefully is this: “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 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 x 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 x the bug, you should include all these things:
22.1 Have you found a bug? 287