Filter
Top Products
• 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 nd 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 nd 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 nd the facts.
22.2 How to report bugs 363