Re: [gdbserver] fix spurious SIGTRAPs

[Pedro Alves <pedro at codesourcery dot com>]

On Wednesday 25 March 2009 22:39:22, Pedro Alves wrote:

> On Thursday 12 March 2009 02:45:21, Pedro Alves wrote:
> > While working on multi-process/non-stop gdbserver, using my favorite
> > multithreaded test, I noticed that gdbserver sometimes would report
> > spurious SIGTRAPs.
> > 
> > Here's what would happen:
> > 
> > The test consists of several threads all running the same loop.
> > There is a breakpoint set in the loop, hence all threads may hit it.
> > The test then issues several "next" commands in a loop.
> > 
> > Here's what would happen in gdbserver:
> > 
> > 1) We issue a "continue", and wait until a thread hits the
> >    breakpoint.  Could be any thread, but assume thread 1 hits it.
> > 
> > 2) We issue a "next" --- this single-steps thread 1, and resumes all
> >    other threads.
> > 
> > 3) thread 2, due to scheduler-locking off, hits the breakpoint.
> >    gdbserver stops all other threads by sending them SIGSTOPs.
> > 
> > 4) While being stopped in step 3, thread 1 reports a SIGTRAP, that
> >    corresponds to the finished single-step of step 2.  gdbserver
> >    leaves the SIGTRAP pending to report later.
> > 
> > 5) We issue another "next" --- this requests thread 2 to
> >    single-step, and all other threads to continue, including thread
> >    1.  Before resuming any thread, gdbserver notices that it
> >    remembers from step 4 a pending SIGTRAP to report for thread 1,
> >    so reports it now.
> > 
> > 6) From GDB's perpective, this SIGTRAP can't represent a finished
> >    single-step, since thread 1 was not single-stepping (it was
> >    continued in step 5).  Neither does this SIGTRAP correspond to a
> >    breakpoint hit.  GDB reports to the user a spurious SIGTRAP.
> > 
> >    Older GDBs happened to paper over the problem, as
> >    clear_proceed_status used to only clear the status of one thread.  As
> >    a side effect, GDB resumed the threads that hit such
> >    spurious SIGTRAPs.
> > 
> > To fix this, when stopping all threads to report a stop to GDB,
> > if we find a thread stops with a SIGTRAP due to a finished single-step,
> > do not leave the SIGTRAP pending.
> > 
> > Tested against x86_64-linux gdbserver, new test included.
> > 
> > OK to apply?

Daniel mentions that he has no time to review these
gdbserver patches, and told me to review them
myself.  :-)

If nobody objects, and if there are no comments on the patches
themselves, I'll apply this patch, and the others that add
non-stop + multiprocess support to gdbserver.

-- 
Pedro Alves