But to the new user, these bugs are nothing more than a nuisance, getting in the way of things “just working”. Those new users need help in understanding that bugs in Linux should be reported to the developers. But how do you do it? A new user isn’t going to be savvy enough to run a backtrace on a segfaulting piece of software.  In this article I am going to attempt to help the new user to see how easy it can be to report bugs as well as how and/or where to report them.

What is a “bug”?

I would venture a guess that most everyone viewing this site knows what a “bug” is, in reference to computer software. But just in case you don’t…

When referring to a “bug” on a computer, it is always referring to a software bug. This means that somewhere, within the code, there is a problem that can only be resolved by fixing the code (there are, of course, exceptions.) In Linux you will find bugs will show up in strange ways. Sometimes a program simply won’t start. Or some times a program will start but give you an error (sometimes a rather saucy error).

It’s when a program doesn’t launch that bugs become really problematic. Why? How do you know what is going on? The first, and best, way to figure this out is by launching the program from the command line (instead of the menu).  This will often give you some indication as to what is going on. From this “indication” you can often google the error and find a resolution. But what happens if you find no resolution? That is when tools come in to play.

Linux bug tools

The first tool many developers will want you to use is strace. This application is a way to run a buggy piece of software and get returned a log file that is very helpful to developers. So when you have a piece of software that will not start (say it exits with a segmentation fault) you can start the application using strace like so:

strace -o OUTPUT_FILE /PATH/TO/EXECUTABLE

Where OUTPUT_FILE is the file you want to output the debug info to and /PATH/TO/EXECUTABLE is the explicit path to the executable file. NOTE: You MUST use the complete (explicit) path to the executable or the program will not execute.

The file containing the debug info is precious manna for developers trying to squash bugs in software. Attaching it to bug reports is more helpful than anything.

Most distributions have specific web sites dedicated to reporting bugs. For example: Ubuntu uses Launchpad for bug reporting. Red Hat uses Bugzilla for bug reporting. OpenSuSE has their own bug reporting site. If you are interested in helping make your favorite distribution better, make sure you know the site for reporting bugs.

There are also tools, like BugBuddy, that are useful for reporting bugs (which I will address in a later article).

Final thoughts

The single most important issue with reporting bugs is to make sure you collect as much information about the bug as possible. Armed with that information, you will be a big help to the developers of the application and that bug will get squashed.

We live in an imperfect world full of bugs (and other insects of course) and the cyber-world is no exception to that rule. Fortunately, there are several ways to resolve problems, as long as you have any idea of what caused them to happen. Not all error messages or bug reports are as useless (and funny) as the one I mentioned above. Most of them provide you with at least a brief description of the error and mostly an error number or category as well. But what if you don’t understand the error message? How about asking some other users who could have experienced it or know how to fix it ?

Bug.gd (Beta) is a rather simple service that allows you to search the library of bugs with their solutions and shows a list of reports you might be interested in. You can search for the error number, description or whatever else provided.

Besides that, you can also help other people to resolve some bugs by posting a solution to an unsolved problem. The only thing that is required of you is to provide your e-mail address. Try this service out by typing in a well-known error number like 404 and watch the amount of explanations you get for your problem. It’s not limited to any specific type of bugs / errors.