Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* RFC: fix race in multiexec case
@ 2010-01-05  8:27 Vladimir Prus
  2010-01-06 16:32 ` Pedro Alves
  0 siblings, 1 reply; 5+ messages in thread
From: Vladimir Prus @ 2010-01-05  8:27 UTC (permalink / raw)
  To: gdb-patches


While testing my MI multiexec support patches, I've got GDB to crash. What happened
is that:

- inferior 1 is run
- MI switches to inferior 2, which is never run. inferior_ptid gets set to
  null_ptid
- MI tries to run inferior 2
- GDB noticed gets an even in inferior 1
- handle_inferior_event calls get_current_regcache()
- get_current_regcache() calls get_thread_regcache (inferior_ptid),
  and inferior_ptid is still null_ptid
- get_thread_regcache indirectly calls linux_nat_thread_address_space,
and it has a code like this:

  if (GET_LWP (ptid) == 0)
    {
      ...
      lwp = find_lwp_pid (ptid);
      pid = GET_PID (lwp->ptid);
    }

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.
Maybe, inferior_ptid should be reset much earlier?

Thanks,
Volodya


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


- Volodya


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: RFC: fix race in multiexec case
  2010-01-05  8:27 RFC: fix race in multiexec case Vladimir Prus
@ 2010-01-06 16:32 ` Pedro Alves
  2010-01-08 14:10   ` Vladimir Prus
  0 siblings, 1 reply; 5+ messages in thread
From: Pedro Alves @ 2010-01-06 16:32 UTC (permalink / raw)
  To: gdb-patches; +Cc: Vladimir Prus

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.

> Maybe, inferior_ptid should be reset much earlier?

Yes, at some point, we should clean this all up and context switch
as soon as we see an event, like in non-stop (fetch_inferior_event).
Not much point in not doing so, now that the globals that formed
the supposed "context" are gone.

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

-- 
Pedro Alves


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: RFC: fix race in multiexec case
  2010-01-06 16:32 ` Pedro Alves
@ 2010-01-08 14:10   ` Vladimir Prus
  2010-01-08 14:23     ` Pedro Alves
  0 siblings, 1 reply; 5+ messages in thread
From: Vladimir Prus @ 2010-01-08 14:10 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb-patches

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: RFC: fix race in multiexec case
  2010-01-08 14:10   ` Vladimir Prus
@ 2010-01-08 14:23     ` Pedro Alves
  2010-01-08 16:54       ` Vladimir Prus
  0 siblings, 1 reply; 5+ messages in thread
From: Pedro Alves @ 2010-01-08 14:23 UTC (permalink / raw)
  To: Vladimir Prus; +Cc: gdb-patches

On Friday 08 January 2010 14:09:55, Vladimir Prus wrote:

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

Just the regular testing is fine.

-- 
Pedro Alves


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: RFC: fix race in multiexec case
  2010-01-08 14:23     ` Pedro Alves
@ 2010-01-08 16:54       ` Vladimir Prus
  0 siblings, 0 replies; 5+ messages in thread
From: Vladimir Prus @ 2010-01-08 16:54 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb-patches

[-- Attachment #1: Type: Text/Plain, Size: 363 bytes --]

On Friday 08 January 2010 17:23:35 Pedro Alves wrote:

> On Friday 08 January 2010 14:09:55, Vladimir Prus wrote:
> 
> > 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?
> 
> Just the regular testing is fine.

Thanks. Tested and checked in now.

- Volodya

[-- Attachment #2: final.diff --]
[-- Type: text/x-patch, Size: 1327 bytes --]

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.11212
diff -u -p -r1.11212 ChangeLog
--- ChangeLog	8 Jan 2010 13:54:40 -0000	1.11212
+++ ChangeLog	8 Jan 2010 16:53:31 -0000
@@ -1,3 +1,9 @@
+2010-01-08  Vladimir Prus  <vladimir@codesourcery.com>
+
+	Fix multiexec race.
+	* infrun.c (handle_inferior_event): Use get_thread_regcache
+	with events ptid, not get_current_regcache.
+
 2009-01-08  Joel Brobecker  <brobecker@adacore.com>
 
 	GDB crash with empty executable name (MinGW).
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.423
diff -u -p -r1.423 infrun.c
--- infrun.c	5 Jan 2010 20:55:18 -0000	1.423
+++ infrun.c	8 Jan 2010 16:53:31 -0000
@@ -3232,7 +3232,8 @@ targets should add new threads to the th
   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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-01-08 16:54 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-05  8:27 RFC: fix race in multiexec case Vladimir Prus
2010-01-06 16:32 ` Pedro Alves
2010-01-08 14:10   ` Vladimir Prus
2010-01-08 14:23     ` Pedro Alves
2010-01-08 16:54       ` Vladimir Prus

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox