From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4871 invoked by alias); 22 Jul 2006 20:02:16 -0000 Received: (qmail 4857 invoked by uid 22791); 22 Jul 2006 20:02:15 -0000 X-Spam-Check-By: sourceware.org Received: from nf-out-0910.google.com (HELO nf-out-0910.google.com) (64.233.182.185) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 22 Jul 2006 20:02:13 +0000 Received: by nf-out-0910.google.com with SMTP id k26so1301969nfc for ; Sat, 22 Jul 2006 13:02:09 -0700 (PDT) Received: by 10.78.177.11 with SMTP id z11mr904481hue; Sat, 22 Jul 2006 13:02:09 -0700 (PDT) Received: by 10.78.33.8 with HTTP; Sat, 22 Jul 2006 13:02:09 -0700 (PDT) Message-ID: Date: Sat, 22 Jul 2006 20:09:00 -0000 From: "Mike Wellington" To: insight@sourceware.org, gdb@sourceware.org Subject: plain/text: Re: insight/gdb stops single-stepping multi-threaded application - newbie question Cc: mike.b.wellington@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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-07/txt/msg00146.txt.bz2 I sent the first post in HTML by mistake. sorry. On 7/22/06, Mike Wellington wrote: > > > > Hello - > I am trying to debug a multi-theaded application with Insight-6.0/gdb-6.0 > on a PowerPC 4xx processor, the kernel is a modified Linux 2.6.0. > > I set a non-thread-specific breakpoint at a location that is > reached regularly. I use a gdb user macro to "continue" each time > the breakpoint is reached. I start the application. The application > creates and starts about 25 threads. After the breakpoint > has been reached 50 - 80 times, the debugger stops - a continue > is entered - but the thread that hit the breakpoint is never run > again. > ---- > 1) Has anyone seen this problem, or one similar to it, before? > ---- > This only occurs after the single step after the breakpoint is > performed. On the target side I have verified with a printk that > the breakpoint was hit, then a single-step is performed, then > the breakpoint trap is never encountered after that. > > If I do a "ps" on the target system at this point I can see that > 4-10 threads are all in the 'T' or stopped state. If I send a SIG_CONT > to the threads then things start running again, for a little while. > > I set "int debug_threads" = 1;" inside gdb/gdbserver/linux- low.c > I also added some other printfs to try to see what was going on. > > When a continue after a breakpoint is executed there are a > series of ptrace( ) calls that are executed to restart the > thread that hit the breakpoint. The registers are read, and written, > some other PEEKS and POKES of the thread's memory space are > done - then the last ptrace( ) is the one that performs a PTRACE_CONT > to signal the thread to run again. > > Well, while these commands are being executed I see a call to > ptrace execute a PTRACE_CONT with the "data" parameter set to > 0. for a different thread. Then the rest of the ptrace calls > to restart the breakpointed thread are executed. > > The thread never hits the next breakpoint,. All I see are continued > PTRACE_CONT for a different thread with 32 as the signal. The > thread that repeatedly signals is in a rt_sigsuspend () > system call. > > ------ > 2) I don't know if the breakpoint failure has anything to do with the > recurring asynchronous PTRACE_CONT from rt_sigsuspend() occuring > while gdbserver is trying to restart after a breakpoint / singlestep, but it > looks suspicious. > ----- > > If anybody knows anything about what might cause this problem > and/or how to fix it I would really appreciate the help. > > thanks > > > -mike > >