Re: [RFC]: Ugly thread step situation

[Daniel Jacobowitz <drow@false.org>]

On Wed, Sep 15, 2004 at 01:36:13PM -0400, Jeff Johnston wrote:
> Daniel Jacobowitz wrote:
> >On Tue, Sep 14, 2004 at 05:44:47PM -0400, jjohnstn wrote:
> >
> >>I recently tracked down a problem with gdb on RHEL3 Linux regarding 
> >>stepping threads.  What happens is that in some instances, lin-lwp.c is 
> >>asked to step the thread of interest.  We then wait on all threads.  Due 
> >>to some form of race condition, the wait does not get back the trap from 
> >>the stepped thread.  If we have a number of waiting events (e.g. thread 
> >>create events, other breakpoints), lin-lwp picks one of them.
> >
> >
> >Could you explain this bit a little more?  What comes back instead for
> >the thread that was stepping?  Do we stop it with a SIGSTOP?
> >
> >Is there a testcase?
> >
> 
> Attached.  This was the test-case given for Red Hat Bugzilla bug 130896.

Given Andrew's caveat, I will just look at the trace instead.  I see
that bug isn't publicly visible.

> LLR: PTRACE_SINGLESTEP process 10066, 0 (resume event thread)
> LLW: waitpid 10062 received Trace/breakpoint trap (stopped)
> LLTA: PTRACE_PEEKUSER LWP 10062, 0, 0 (OK)
> LLW: Candidate event Trace/breakpoint trap (stopped) in LWP 10062.
> SC:  kill LWP 10068 **<SIGSTOP>**
> SC:  lwp kill 0 ERRNO-OK
> SC:  kill LWP 10067 **<SIGSTOP>**
> SC:  lwp kill 0 ERRNO-OK
> SC:  kill LWP 10066 **<SIGSTOP>**
> SC:  lwp kill 0 ERRNO-OK
> WL: waitpid LWP 10068 received Stopped (signal) (stopped)
> WL: waitpid LWP 10067 received Trace/breakpoint trap (stopped)
> PTRACE_CONT LWP 10067, 0, 0 (OK)
> SWC: Candidate SIGTRAP event in LWP 10067
> WL: waitpid LWP 10067 received Stopped (signal) (stopped)
> WL: waitpid LWP 10066 received Stopped (signal) (stopped)
> FC: LP has pending status 00057f
> SEL: Found 2 SIGTRAP events, selecting #0  <=== should not happen
> CBC: Push back breakpoint for LWP 10062
> LLW: trap_ptid is LWP 10067.
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> [Switching to Thread -1231361104 (LWP 10067)]
> 0x080489cb in synchronize (tid=3063606192) at gdbtest.C:18
> 18	    pthread_mutex_lock(&mutex);

In this trace, we single-step process 10066 [we resumed all the other
threads first - I snipped too much].  Then we wait.  We receive an
event from 10062.  We stop all other threads.  We receive another event
from 10067, and a SIGSTOP from 10066 and 10068.  So the thread had not
yet been scheduled when we sent it the SIGSTOP, and it hasn't done the
single step yet.

If I am interpreting your patch correctly, it will cause us to use
waitpid without __WNOHANG on LWP 10066.  If 10066 is stepping over a
blocking syscall, and another thread hits a breakpoint, we want to
display the breakpoint.  Otherwise we'll get the wrong behavior in the
non-race-condition situation where one thread goes to sleep.

Infrun needs to verify that the thread which had an event was the
thread which stepped.  If it isn't, then hopefully the single-step has
not happened - this will be true using x86 and PTRACE_SINGLESTEP, but
may require some other changes for software singlestep that I think I
have queued somewhere.


-- 
Daniel Jacobowitz