From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1051 invoked by alias); 24 Mar 2006 20:15:40 -0000 Received: (qmail 998 invoked by uid 22791); 24 Mar 2006 20:15:39 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 24 Mar 2006 20:15:32 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FMsgw-00072m-R2; Fri, 24 Mar 2006 15:15:26 -0500 Date: Fri, 24 Mar 2006 20:27:00 -0000 From: Daniel Jacobowitz To: John Fodor Cc: gdb@sourceware.org Subject: Re: gdb and multi-threaded (NPTL) programs Message-ID: <20060324201526.GA26907@nevyn.them.org> Mail-Followup-To: John Fodor , gdb@sourceware.org References: <44244F1F.6030108@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44244F1F.6030108@mac.com> User-Agent: Mutt/1.5.8i 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/msg00173.txt.bz2 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