Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Corinna Vinschen <vinschen@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: [RFA] attach_command: clear solib state before attaching to process
Date: Mon, 17 Jan 2005 14:54:00 -0000	[thread overview]
Message-ID: <20050117145425.GP3113@cygbert.vinschen.de> (raw)

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.


             reply	other threads:[~2005-01-17 14:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-17 14:54 Corinna Vinschen [this message]
2005-01-17 16:27 ` Kevin Buettner
2005-01-17 16:49   ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050117145425.GP3113@cygbert.vinschen.de \
    --to=vinschen@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox