plain/text: Re: insight/gdb stops single-stepping multi-threaded application - newbie question

["Mike Wellington" <mike.b.wellington@gmail.com>]

I sent the first post in HTML by mistake.  sorry.

On 7/22/06, Mike Wellington <mike.b.wellington@gmail.com> 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
>
>