Better Bug Reports for Better Help
Doghouse – Bug Reports
For a better bug report, maddog offers a refresher course on crafting a clear statement that will help get your problem fixed.
A blog I read from time to time had a short article complaining about "bug reports" and bemoaning the fact that users telling the programmers "it broke" was somehow not good enough. I have written articles about writing bug reports in magazines and books over the years, but apparently a "refresher" is needed every once in a while. Plus, containers, virtual machines, and more modern processors make things more complicated.
Specify the Problem
First, try to determine whether the problem is a true problem rather than you just do not know what to do when you want to do it. If it is the second issue, then search in whatever documentation exists. Many large applications (word processing systems, projects of every kind) have fairly good documentation in their online Help menu.
After looking through the documentation, you might search the Internet to see if someone else is having the same problem. A few well-worded queries in your favorite browser may find other people with the same problem, and you may find a way of working around the issue. If it still seems that people are just not understanding the documentation, then that is still a problem and should be reported. After all, it is causing people frustration and wasting time, so it is still a bug, but now you have more insight into the issue.
You now have done about all you can do before assuming the problem really is the application code, or perhaps the system. Next, you need to describe the problem to someone, somewhere, who can fix it.
Provide Information
Start gathering information about your problem. What software version and release number are you using? You can usually find this in the Help documentation. Do not only supply the application information, but also give information for the operating system on which you are running the application.
Include the distribution name (Ubuntu, Mint, Red Hat, etc.), version number, and release (or revision) number of the operating system. You also want to get the version number and release number of the kernel, which will probably be different. You can easily find the kernel information by typing in uname -a
into a terminal emulator, for example:
$ uname -a: Linux shaman 5.4.0-80-generic #90~18.04.1-Ubuntu SMP Tue Jul 13 19:40:02 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
To find the information you need for the kernel, look at the output following the name of your machine, in this example "shaman
".
What architecture is your system? Is it Intel, AMD, ARM, or RISC-V? How many cores does your processor have, or specifically, what is your processor's model number?
How much main memory do you have?
Are you running the operating system in a virtual machine (VM)? What is the VM's version and what are the settings?
Are you running the application in a container? Give as much information about the container as possible.
Try to make your environment as simple as possible. See if the problem remains when you run it directly on a distribution and the distribution directly on the hardware of the machine.
To make this a lot easier, many systems have a command that tells you all the necessary information with one click. All you have to do is cut and paste or direct the information into a file.
If your application uses a browser, state which browser name and version you are using.
Report the Facts
Now you should make a clear statement of what is wrong. Be as precise as possible. Do not say "it broke." What "broke"? What did the program do or not do? Take a screen shot, if possible. Supply an example of input and output.
If the system crashed, do not just say "it crashed." It may have been the web browser, the X server, or the operating system. Be clear: "The X-server seems to have crashed. The screen went blank for a couple of seconds, but it came back quickly." Or perhaps, "The screen went blank and the operating system rebooted."
If the system is "hung," describe what else happens. Is it only one window that is not responsive or all the windows? Does anything move or react?
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs