Debugging applications that use POSIX threads can by a challenge. Most commercial versions of pthreads provide specially modified version of native debuggers. Even these are really not effective for concurrency problems, though, because they disrupt program execution too much.

Threads on Linux are an even greater challenge. User-level pthreads implementations, like Patched MIT Pthreads can use gdb, but it is not thread-aware.

The situation is much worse with LinuxThreads: gdb is of no help as it will debug only the main thread. It has no control over the other threads, because each are their own process (created with the new Linux clone() system call). Setting any breakpoints will cause a crash. Post-mortem debugging is impossible, because the core file gets corrupted as the dying threads all try to write to it simultaneously. The only hope is printf(), assert() and the DBUG package detailed below.


DBUG by Fred Fish (a macro based C debugging package)

DBUG is an example of an internal debugger, because it requires internal instrumentation of a program

Monty has made it thread-safe and uses it to debug MySQL. It looks like a good way to debug kernel-based LinuxThreads for which gdb is of no help.

DBUG has its own local web page

Very simple thread-safe debug macros

  • Acts like a glorified printf that is thread-safe, removable and can be turned on my module.
  • Stolen from Sun's tgrep sample application, then modified.
  • Sample output [Template: Module Name (thread id): message]:
                All Levels (135366912): 200: Resource succesfully read
                User Session Thread (134737152): Got message from client: summarize
                Command Module (134737152): Keyring file is set at keyring
                
  • Source code in two small files: debug.c and debug.h

SmartGDB

  • Proposal to incorporate modifications into Patched MIT Pthreads
  • Can be found at the SmartGDB Homepage

Using invariants and assert

  • The assert statement
  • Invariants

Good Ole printf

  • Fall back tracing tools
  • Easily implemented


If you have comments or suggestions, email me at sdybiec@humanfactor.com