This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb and multi-threaded (NPTL) programs


Daniel Jacobowitz wrote:
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.

Sounds like a good idea. Let me know how it goes :)




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.

I wasn't referring to sem_wait specifically. I was thinking of any general syscall that will return EINTR after a SIGALARM. But you're right, could be some other signal.




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!


If you use signals you can set SA_RESTART for catchable signals. What we're talking about here is a syscall wrapper just so we can single-step with gdb. Lot's of S/W examples don't have these wrappers. Anyway I do appreciate you help. Thanks.


Can someone send me a nice wrapper macro?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]