Re: gdb and multi-threaded (NPTL) programs

[Daniel Jacobowitz <drow@false.org>]

On Fri, Mar 24, 2006 at 02:57:19PM -0500, John Fodor wrote:
> "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.

Really, in my opinion, it's a kernel bug; the syscall should
automatically restart in this case.  Some syscalls now do that, on
current kernels.  Others don't.  It's hard to fix this without breaking
them in other ways.

In this case the syscall is sys_futex.  When interrupted, futex_wait
returns -EINTR.  This is documented to happen whether the signal was
handled or not.  Maybe adding a fifth signal restart option to the
existing four in the Linux kernel could fix this: ERESTARTNOSIGNAL.
That wouldn't be hard to implement if you want to try it.  You'd have
to do some thinking about the semantics of futexes to make sure it was
safe.

> 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.

Let's be precise here: "what if it's a real signal".  sem_wait does not
time out.  sem_timedwait returns ETIMEDOUT, not EINTR, for timeouts.

> 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?

In practice this does not bother most programmers.  If your application
uses signals, it often needs to do this anyway!

-- 
Daniel Jacobowitz
CodeSourcery