Difference between revisions of "Bug Reporting"

Latest revision as of 10:03, 25 November 2005

Like all software, ETPro has bugs. Clear and accurate bug reports are the best way to ensure they get fixed as quickly as possible. Bad bug reports tend to get ignored, even if there is a genuine bug at their core. Writing good bug reports requires the reporter to spend time and effort doing the preliminary investigation, but that effort is rewarded.

Where to report bugs

• If the bug is a serious security or game exploit, report to Bani or another ETPro Developer using a private message on the ETPro Forums
• If the bug is not a serious exploit, report it on the ET Bugs Forum or ETTV Forum as appropriate. If the bug is specific to a recent release, you may report it in the release thread in the ETPro News Forum
• You may report bugs to the developers on IRC. However, this depends on the developer being available at that time, and risks that they may forget about it, leaving no record of the bug. IRC is extremely useful in cases where the developers need more information, or want to see the bug in action. A good policy is to post the detailed bug report on the forum, and then, if the situation warrants, follow up on IRC, referring to your forum post. This lets them easily see the details of the bug (and any supporting screenshots/logs/demos)

How to write useful bug report

Below are some general guidelines relevant to ET/ETTV/ETPro bugs.

• Search the forum for previous reports

You may find that your bug is already known, or your report may provide additional information relating to a bug that isn't fully understood. If your bug involved a specific error message, search for that.

• Describe clearly what happened, and how that differs from what was expected

A report like "omgz revives are bugged" doesn't give any useful information, and is likely to be dismissed as #whine. A better report would be "at time T in this demo, I try to revive wolfplayer, and after I hit him with the needle we are both stuck in the ground..."

• Post the exact text of any error messages

If the bug results in error messages in the console use the /condump command to save the text, or copy it from a log file. If the error shows up on the screen in some other way, you may be able take a screenshot. If you must manually transcribe the message, do it accurately. Don't say "some error about configs" when the actual error was "CONFIGSTRING > MAX_CONFIGSTRINGS"

• If the bug involves a crash, follow the crash logging guidelines

• for client and server crashes, ETPro 3.2.2-test and above:

set the cvar b_crashlogpath to the path you want to want to save crashdump files to. e.g. on win32 set b_crashlogpath c:\ and on linux, set b_crashlogpath /home/etserver

on win32 you can enable a gui crash popup window with b_crashpopup 1 - !!warning!! server will be halted until the crash dialog box is closed.

• for older versions see these threads Server Client

• Include any relevant system configuration information

If you are reporting a server crash, the operating system and ETTV/ETPro versions are relevant. Unless the hardware is unusual, the exact model of CPU, type of harddisk etc. are probably not.

• Do not post extraneous information or commentary

If the bug involves votes not getting counted correctly, the developers don't need to know what video card you are using.

• Support your bug report with screenshots or demos

Screenshots can show graphical errors, or the location a certain bug happens. Demos can often show the exact sequence of events that trigger the bug. However, be aware that demo playback is not exactly the same as real play, so things that show up in one may not show up in the other. ETTV demos can be used to support ETTV bug reports.

• If the bug is reproducible, describe the exact steps to reproduce the bug

If you can trigger a bug on demand, write down the exact steps to do so, including any relevant configuration settings.

• Use links for large images, logfiles etc.

• Don't make assumptions, just state the facts as you observed them

Additional Reading

Simon Tatham's essay is an excellent description of good bug reporting.