Skip to Content

Debugging session and effective bug reporting session notes.

MSameer's picture

Software debugging & effective bug reprting

Bug reporting,

  • How to report an annoying feature and/or requesting a new feature in an application.
    • BE NICE!
    • Talking to the developer and/or explaining why this feature is annoying or why this missing feature is important is a big plus "When I explained why the libwxgtk should be compiled with unicode/gtk2 support is important for Arabic language, The package maintainer got interested".


  • What is debugging, What's a debugger ?
  • The GNU debugger "gdb"
  • Compiling applications with debugging symbols.
    • Removing the debugging symbols
      • Obtaining a meaningful back trace.
        • What's a back trace ?

      A list of steps by the application or a list of function calls lead to this situation.

      • What is a core file ? What's a core dump ?

      Simply the memory of the application is being dumped to a file!

      • Getting a useful back trace:
        • we must compile with debugging symbols
          • from a core file gdb <application> <core file> where
            • Attaching to another process where

              This is useful if the application is started via a script as openoffice and mozilla.

              • Directly from gdb gdb foo r "When the crash happens: go back to the terminal, You might need to press C-C" where quit
                • How to set break points.

                  Diffs and patches

                  * How to generate a unified diff: diff -Naur <orig> <modified> -N - Treat absent files as empty. -a - treat all files as text -u - Unified diff: -r - recursive

                  • How to exclude: -X <file>
                    • How to apply a patch: --dry-run: Don't really modify files. -p#: strip # leading slashes from the files.
                      • How to remove "unapply" a patch: patch -R -R: Reverse.


                        • Using my CVS server as an example.
                        • How to login. cvs -d:pserver:[email protected]:/var/lib/cvs login export CVSROOT=":pserver:[email protected]:/var/lib/cvs" cvs login
                          • How to checkout. cvs -d:pserver:[email protected]:/var/lib/cvs co projects/illigal or export CVSROOT=":pserver:[email protected]:/var/lib/cvs" cvs -z3 co projects/illigal
                            • How to update. cvs -z3 update
                              • How to request a diff cvs diff -u or cvs diff -u <file>

                                Demonstration of some crashes using my "illigal operation" application

                                • 1: Integer by zero (Random value) - Our code crashed.
                                • 6: strcpy crash! (Copy to a NULL pointer) - here our application caused an external function to crash.


                                • Bugzilla is one of the most widely spreaded bug tracking systems.
                                • Registration:
                                • Submitting a bug:

                                • OpenOffice IssueZilla.
                                • We might have a wizard.
                                • We might have the old complicated method.
                                • Severety "If found": The effect of the bug on the user.
                                  • Blocker: Non usable application.
                                  • Critical: Crashes, causes loss of data, or is a severe memory leak.
                                  • Major: Major loss of functionality
                                • Priority "If found": The importance of the bug
                                  • Immediate: Can't test or use the application or it's a security issue.
                                  • Urgent: I can't use an important features of the application because of it.
                                  • High: Something is broken but the application is still usable.
                                • We have more bug tracking systems like gnats and the debian bug tracking system.

                                strace & ltrace: trace system calls, signals & library calls

                                Notes about interacting with the developers:

                                • Generally be nice and remember that the guy is a volunteer.
                                • Generally don't hijack a thread to include your patch, The patch is a trivial thing, This means that you attach it to the same thread if related, Otherwise start a new thread.
                                • Most people prefere the unified diff format.
                                • Try to stick to the coding standard used by the developer, This is not that important unless you are emailing a kernel patch ;-)
                                • Don't feel angry if the developer tell you that the software is under the GPL and you can do whatever you can.
                                • When reporting a bug, Report either a reproducable bug or the exact steps you followed with a backtrace if you can't reproduce it.


Dr. Radut | book