[RFA] attach_command: clear solib state before attaching to process

[RFA] attach_command: clear solib state before attaching to process

[Corinna Vinschen]

Hi,

I've observed a FAIL of the following test in gdb.base/attach.exp:

  (gdb) attach 4711
  Cannot access memory at address 0xwhatever
  FAIL: gdb.base/attach.exp: attach when process' a.out not in cwd

This happened on a machine running GNU/Linux with glibc 2.3.2.
Further debugging showed that the function first_link_map_member()
in solib-svr4.c happened to access memory which is not in the memory
map of the process which GDB tried to attach to.

What happens is that shared libs are not necessarily mapped to the same
virtual address in different processes.  But GDB does not invalidate
the solib state or in other words, does not reset the static variable
debug_base back to 0 to force to reload the address information when
attaching to another process.  Therefore there's a pretty good chance
for the debug_base pointer to point into nirvana when attaching to
another process, leading to the above problem.

The below patch avoids that problem by calling CLEAR_SOLIB in attach_command,
before the target process gets attached to.

Ok to apply?


Corinna

	* infcmd.c (attach_command): Call CLEAR_SOLIB if available.

Index: infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.125
diff -u -p -r1.125 infcmd.c
--- infcmd.c	14 Jan 2005 00:48:32 -0000	1.125
+++ infcmd.c	17 Jan 2005 14:34:17 -0000
@@ -1776,6 +1776,26 @@ attach_command (char *args, int from_tty
 	error ("Not killed.");
     }
 
+  /* Clear out solib state. Otherwise the solib state of the previous
+     inferior might have survived and is entirely wrong for the new
+     target.  This has been observed on Linux using glibc 2.3. How to
+     reproduce:
+
+     bash$ ./foo&
+     [1] 4711
+     bash$ ./foo&
+     [1] 4712
+     bash$ gdb ./foo
+     [...]
+     (gdb) attach 815
+     (gdb) detach
+     (gdb) attach 4711
+     Cannot access memory at address 0xdeadbeef
+  */
+#ifdef CLEAR_SOLIB
+      CLEAR_SOLIB ();
+#endif
+
   target_attach (args, from_tty);
 
   /* Set up the "saved terminal modes" of the inferior

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Re: [RFA] attach_command: clear solib state before attaching to process

[Kevin Buettner]

On Mon, 17 Jan 2005 15:54:25 +0100
Corinna Vinschen <vinschen@redhat.com> wrote:

> Hi,
> 
> I've observed a FAIL of the following test in gdb.base/attach.exp:
> 
>   (gdb) attach 4711
>   Cannot access memory at address 0xwhatever
>   FAIL: gdb.base/attach.exp: attach when process' a.out not in cwd
> 
> This happened on a machine running GNU/Linux with glibc 2.3.2.
> Further debugging showed that the function first_link_map_member()
> in solib-svr4.c happened to access memory which is not in the memory
> map of the process which GDB tried to attach to.
> 
> What happens is that shared libs are not necessarily mapped to the same
> virtual address in different processes.  But GDB does not invalidate
> the solib state or in other words, does not reset the static variable
> debug_base back to 0 to force to reload the address information when
> attaching to another process.  Therefore there's a pretty good chance
> for the debug_base pointer to point into nirvana when attaching to
> another process, leading to the above problem.
> 
> The below patch avoids that problem by calling CLEAR_SOLIB in attach_command,
> before the target process gets attached to.
> 
> Ok to apply?
> 
> 
> Corinna
> 
> 	* infcmd.c (attach_command): Call CLEAR_SOLIB if available.

Okay.

Kevin

Re: [RFA] attach_command: clear solib state before attaching to process

[Corinna Vinschen]

On Jan 17 09:27, Kevin Buettner wrote:
> Corinna Vinschen <vinschen@redhat.com> wrote:
> > 	* infcmd.c (attach_command): Call CLEAR_SOLIB if available.
> 
> Okay.

Thanks, applied.  I've corrected the explaining comment to use the same
pids in GDB as have been printed in the bash output :-)


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.