This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]