This is the mail archive of the gdb-patches@sourceware.org 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]

Re: RFC: fix race in multiexec case


On Wednesday 06 January 2010 19:31:59 Pedro Alves wrote:

> On Tuesday 05 January 2010 08:26:58, Vladimir Prus wrote:
> 
> > However, find_lwp_pid returns NULL for null_ptid, and this code segfaults.
> > I attach a minimal patch that appears to fix this, but I feel uneasy about it.
> 
> Ah, this bit runs before the almighty context_switch line.  Your fix is correct.
...
> > diff --git a/gdb/infrun.c b/gdb/infrun.c
> > index d8ca40d..300af62 100644
> > --- a/gdb/infrun.c
> > +++ b/gdb/infrun.c
> > @@ -3232,7 +3232,8 @@ targets should add new threads to the thread list themselves in non-stop mode.")
> >    if (ecs->event_thread->stop_signal == TARGET_SIGNAL_TRAP)
> >      {
> >        int thread_hop_needed = 0;
> > -      struct address_space *aspace = get_regcache_aspace (get_current_regcache ());
> > +      struct address_space *aspace =
> > +       get_regcache_aspace (get_thread_regcache (ecs->ptid));
> > 
> >        /* Check if a regular breakpoint has been hit before checking
> >           for a potential single step breakpoint. Otherwise, GDB will
> > 
> 
> This is OK.

What is the right way to regression test this? Do you think running testsuite with no special
arguments is sufficient, or I need to try async/non-stop?

- Volodya


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