Dealing with bugs in Linux

Jack Wallen
Feb 9, 2010
Updated • Dec 27, 2012
Linux
|
4

One of the things I've always liked about using Linux is the feeling that my input is actually important. Either by way of giving input to the developers directly or (more importantly) reporting bugs that inevitably appear on a system. It's the latter of the two that help Linux (as a whole) to take great strides forward. Without a community of users and developers to report problems, the operating system would stagnate.

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.

Advertisement

Previous Post: «
Next Post: «

Comments

  1. Wayne Allen said on February 19, 2010 at 8:25 pm
    Reply

    If you don’t want to deal with managing a Bugzilla instance yourself you can use our hosted Bugzilla service:
    http://www.devzing.com/bugzilla.php

  2. an0n said on February 9, 2010 at 8:05 am
    Reply

    forgot about ‘gdb’ and the debug dev symbols…

Leave a Reply

Check the box to consent to your data being stored in line with the guidelines set out in our privacy policy

We love comments and welcome thoughtful and civilized discussion. Rudeness and personal attacks will not be tolerated. Please stay on-topic.
Please note that your comment may not appear immediately after you post it.