Contributed by Dengue on from the download-a-snapshot-today dept.
How to create a problem report
Always provide as much information as possible. Try to pin-point the exact problem. Never give vague instructions, or detail vague problems like "it crashes or "I get strange interrupt issues on this one box that I built." Talk to others on IRC or some other forum to confirm that it is new, repeatable, etc. and make sure it is not a local problem.
Please don't start fixing problems that require significant work until you are sure you understand them, especially during our release periods when we must not change major sections of code. If you are going to write significant amounts of code, check various forums to make sure that someone else is not working on the problem (saving duplication of effort).
The following items should be contained in every bug report:
- The exact sequence of steps from startup necessary to reproduce the problem. This should be self-contained; it is not enough to send in a bare command without the arguments and other data you supplied to it. If a bug requires a particular sequence of events, please list those. You are encouraged to minimize the size of your example, but this is not absolutely necessary. If the bug is reproducible, we'll find it either way.
- The output you got. Please do not say that it "didn't work" or "failed". If there is an error message, show it, even if you don't understand it. If OpenBSD panics with a particular error, say which. If nothing at all happens, say so. Even if the result of your test case is a program crash or otherwise obvious it might not happen in our testing. The easiest thing is to copy the output from the terminal, if possible. Note: In case of fatal errors, the error message provided might not contain all the information available. In that case, also look at the output in the system log files, such as those stored in /var/log. Also, if you are dealing with an application that has its own log files, such as httpd, check for errors where it keeps its logs (in the case of httpd, this is /var/www/logs).
- The OpenBSD kernel output. You can get this with the dmesg command, but it is possible that your dmesg output does not contain all the information that is captured in /var/run/dmesg.boot. If this is the case, include information from both. Please include this in all bug reports.
- If you run third-party software which has to do with your bug, say so, including any subversion that software may have. If you are talking about a CVS or FTP snapshot, mention that, including its date and time.
- A traceback from your kernel panic. If your kernel panic'ed, and you are at a ddb> prompt where you can type traceback, then please do so. Submit the traceback output in your bug report. This is essential whenever possible.
Do not be afraid if your bug report becomes rather lengthy. That is a fact of life. It's better to report everything the first time than us having to squeeze the facts out of you. On the other hand, if your input files are huge, it is fair to ask first whether somebody is interested in looking into it.
Finally, when writing a bug report, please choose non-confusing terminology.
(Comments are closed)