From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17348 invoked by alias); 24 Mar 2006 19:58:58 -0000 Received: (qmail 17335 invoked by uid 22791); 24 Mar 2006 19:58:57 -0000 X-Spam-Check-By: sourceware.org Received: from yosemite.airs.com (HELO yosemite.airs.com) (205.217.158.180) by sourceware.org (qpsmtpd/0.31) with SMTP; Fri, 24 Mar 2006 19:58:54 +0000 Received: (qmail 21218 invoked from network); 24 Mar 2006 19:58:45 -0000 Received: from smtpout.mac.com (17.250.248.86) by yosemite.airs.com with SMTP; 24 Mar 2006 19:58:45 -0000 Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout04/MantshX 4.0) with ESMTP id k2OJwPMc020870 for ; Fri, 24 Mar 2006 11:58:25 -0800 (PST) Received: from [10.35.3.20] ([216.191.234.70]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id k2OJwNZv009744 for ; Fri, 24 Mar 2006 11:58:25 -0800 (PST) Message-ID: <44244F1F.6030108@mac.com> Date: Fri, 24 Mar 2006 20:24:00 -0000 From: John Fodor User-Agent: Mozilla Thunderbird 1.0.7-1.4.1.centos4 (X11/20051007) MIME-Version: 1.0 To: gdb@sourceware.org Subject: gdb and multi-threaded (NPTL) programs 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/msg00172.txt.bz2 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