0.2 Submitting bug reports  (Page 2/4)

If you have to report a bug to a programmer who can't be present in person (or via remote support tools), then you want to ensure they can reproduce the problem. If they can't, they may have to assume that there's a user error.

Report exactly what you did leading up to the error. If it's a graphical program, report exactly which buttons you pressed, and in what order you pressed them. If it's a command-line program, capture precisely what command you typed - this is where tools like `script` and `tee` can again come in handy!

Make sure the bug report has all the input you can think of. If the program reads from a file, add a copy of the file. If the program talks to another computer over a network, while you can't send a copy of that device, you can report what kind of system it is, and (if you can) what software is running on it.

"works for me. so what goes wrong?"

If you report a long list of inputs and actions, and the developer(s) attempt to recreate the problem, but nothing goes wrong, then you haven't given them enough information. Possibly the fault doesn't show up on every computer; your system and theirs may differ in some way. Possibly you have misunderstood what the program is supposed to do, and you are both looking at exactly the same display but you think it's wrong and they know it's right.

Therefore, you must also describe what happened. Report exactly what you saw. State why you think what you saw is wrong; better still, explain exactly what you expected to see. If you say something like "and then it went wrong", you have left out a lot of very important information. If you saw error messages, then report, carefully and precisely, what they were - they are important! At this stage, the developer is not trying to fix the problem: they're trying to find it. They need to know what has gone wrong, and those error messages are the system's best effort to tell you that. Write the errors down if you have no other easy way to remember them; it's not worth reporting the program generated an error unless you can also report what the error message was.

In particular, if the error message has numbers in it, do report them! Just because you can't see any meaning in them doesn't mean there isn't any. Numbers contain all kinds of information that can be interpreted by the developers, and they are likely to contain vital clues. Numbers in error messages are there because the computer is too confused to report the error in words, but is doing the best it can to get the important information to you somehow.

At this stage, the programmer is effectively doing detective work - they don't know what's happened, and they can't get close enough to watch it happening for themselves, so they are searching for clues that might give it away: error messages, incomprehensible strings of numbers, and even unexplained delays are all just as important as fingerprints at the scene of a crime. Keep them! If you are using a Unix-like environment, the program may have produced a core dump. Core dumps are a particularly good source of clues, so don't throw them away. Make sure you put in the bug report you have such dumps; the development team may want them added to the case. Be aware that the core file typically contains a record of the complete state of the program: any "secrets" involved (maybe the program was handling a personal message, or dealing with confidential data) may be contained in the core file.