This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
gdb and multi-threaded (NPTL) programs
- From: John Fodor <john_fodor at mac dot com>
- To: gdb at sourceware dot org
- Date: Fri, 24 Mar 2006 14:57:19 -0500
- Subject: gdb and multi-threaded (NPTL) programs
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