Bugs:An application crashed

Introduction

You are working with a program and suddenly the worst happens--it crashes. One convenience of open source software is the open community with their programmers who really listen to their users and try to fix a reported bug as soon as possible. So you, as a normal user, can become part of the community just by reporting bugs and testing the fixed application.

But reporting a bug is not as easy as saying "it doesn't work." One of the factors that delays a bug's being fixed is the way it is reported. So this guide should help improve communication between developers and users in bug resolution.

Qualities of a Good Bug Report

So please remember the two qualities of a good bug report:

• Reproducible: Try to reproduce the bug on your own workstation. Write down every step you take to reproduce the bug. Sometimes it could be helpful to disable background tasks in order to avoid interactions between the crashing application and another process running in the background. If the crashing application interacts with another process, this should also be reported as a bug. Every detail you can provide helps the engineer to reproduce the bug on his own workstation.

• Specific: Don't report more than one bug with a single message. Provide as exact information as you can. Don't talk about other things that might force a programmer or tester to decipher before understanding your message.

For example: Let's say the buggy application is a Web browser. It crashes every time you visit foo.bar and you want to write up a bug report:

BAD: "My browser crashed. I think I was on www.foo.bar.
  I play golf with Bill Gates, so you better fix this problem, 
  or I'll report you to him. By the way, your Back icon
  looks like a squashed rodent. UGGGLY. Thx 4 UR help."

GOOD: "The application crashed each time I went to
  www.foo.bar, using the 2006-04-01 build on a openSUSE system. It 
  crashed again each time upon drawing the Foo banner at the top
  of the page. I broke apart the page, and discovered that the
  following image link will crash the application every time,
   unless you remove the 
         "BORDER=0" attribute:
         <IMG SRC="" WIDTH="400" HEIGHT="44" BORDER="0" ALT="Our Banner">

Analyzing the Problem

Environment

First of all, check your environment. Write down the system version, the program version, plug-ins (adding their versions), and so on. After that, try to reproduce the problem and write down the steps you make to get the application to crash. Find out, if the problem is solved with a newer version of your software: look at the project home page to get more information.

Install -debuginfo Packages

Most GUI applications show you a backtrace on a crash. A backtrace tells the developer more exactly where the error occurred. Usually gdb is used to create this backtrace. However, gdb can create a more detailed backtrace when it has the debug info. Please install the -debuginfo package for your application to improve the output of gdb. The -debuginfo packages are not part of the CD set, but you can find them in the full network installation source, in the "inst-source" directory on our FTP server or any mirror. This directory can be defined as an installation source in YaST (as a replacement for your CD).

Please install the packages and try to reproduce the crash. Attach a description what you did to trigger the crash and the backtrace to the bug report. These packages also help debugging, when you you use gdb directly, see below.

Debugging

There is no update and you can reproduce the problem smoothly. Now it's time to start debugging the application. Debugging could take a lot of time--but sometimes it's the only way to get a good bug report and to help the developers to solve the bug quickly.

There are different ways to debug an application, so you have to check each of these proposals on your own and choose the right form for your application.

strace

Programs often use files to fetch configuration information, access hardware, or write logs. Sometimes, a program attempts to reach such files incorrectly. strace is a useful diagnostic, instructional, and debugging tool and could help deal with this. strace traces system calls (hence the name), which include calls that use the memory and files.

In the simplest case, strace runs the specified command until it exits. It intercepts and records the system calls that are called by a process and the signals that are received by a process. The name of each system call, its arguments, and its return value are printed on standard error or to the file specified with the -o option.

An example for stracing the command cat /dev/null is:

  strace -o strace.log cat /dev/null

This creates a file called strace.log in the current directory. We check the file, the relevant parts of which are shown below:

  open("/dev/null", O_RDONLY) = 3

Errors (typically a return value of -1) have the errno symbol and error string appended.

  open("/foo/bar", O_RDONLY) = -1 ENOENT (No such file or directory)

So strace seems to be the best way to debug applications that crash on start-up or crash while opening or saving files.

Using GDB

GDB, the GNU Debugger, is a program used to find run time errors that normally involve memory corruption.

dmesg

dmesg prints out or controls the kernel ring buffer. So if you have problems with the kernel itself or kernel-related applications (especially kernel modules or hotplug stuff), you should use this tool.