From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16844 invoked by alias); 24 Mar 2006 20:45:30 -0000 Received: (qmail 16836 invoked by uid 22791); 24 Mar 2006 20:45:29 -0000 X-Spam-Check-By: sourceware.org Received: from smtpout.mac.com (HELO smtpout.mac.com) (17.250.248.70) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 24 Mar 2006 20:45:27 +0000 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/8.12.11/smtpout13/MantshX 4.0) with ESMTP id k2OKjHFh009075; Fri, 24 Mar 2006 12:45:17 -0800 (PST) Received: from [10.35.3.20] ([216.191.234.70]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id k2OKjDXt022718; Fri, 24 Mar 2006 12:45:17 -0800 (PST) Message-ID: <44245A19.8060808@mac.com> Date: Fri, 24 Mar 2006 20:52:00 -0000 From: John Fodor User-Agent: Mozilla Thunderbird 1.0.7-1.4.1.centos4 (X11/20051007) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb@sourceware.org Subject: Re: gdb and multi-threaded (NPTL) programs References: <44244F1F.6030108@mac.com> <20060324201526.GA26907@nevyn.them.org> In-Reply-To: <20060324201526.GA26907@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00177.txt.bz2 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?