Debugging with GDB Manual (5900-1473; WDB 6.2; January 2011)

Table Of Contents
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.
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 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 x 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 x, 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.
22.2 How to report bugs 361