gdb and multi-threaded (NPTL) programs

[John Fodor]

Hi Folks,

A colleague had trouble debugging a multi-threaded (NPTL) program using 
GDB. To see what was going on, I created a purely artificial program 
where 2 POSIX threads synchronize their execution using semaphores. 
While single-stepping one thread, the other thread gets an EINTR error 
from sem_wait. After looking at info gdb (related to threads) I got my 
answer:

"There is an unfortunate side effect.  If one thread stops for a
breakpoint, or for some other reason, and another thread is blocked in a
system call, then the system call may return prematurely.  This is a
consequence of the interaction between multiple threads and the signals
that GDB uses to implement breakpoints and other events that stop
execution.

To handle this problem, your program should check the return value of
each system call and react appropriately.  This is good programming
style anyways. For example, do not write code like this:

        sleep (10);

The call to `sleep' will return early if a different thread stops at
a breakpoint or for some other reason. Instead, write this:

        int unslept = 10;
        while (unslept > 0)
          unslept = sleep (unslept);

A system call is allowed to return early, so the system is still
conforming to its specification.  But GDB does cause your
multi-threaded program to behave differently than it would without GDB."

Hmmm... so people who use POSIX threads have to put every syscall into a 
loop, ignoring EINTR? What if it's a real timeout? Sorry this does not 
seem reasonable to me.

Will there be a fix in the future to this unfortunate side-effect? How 
do NPTL programmers single-step their programs today? Using syscalls in 
loops? Using a different debugger?

Thanks for you help.

John