From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10025 invoked by alias); 17 Jan 2005 14:54:52 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9874 invoked from network); 17 Jan 2005 14:54:40 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 17 Jan 2005 14:54:40 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0HEseiK021558 for ; Mon, 17 Jan 2005 09:54:40 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0HEsZO31798 for ; Mon, 17 Jan 2005 09:54:35 -0500 Received: from cygbert.vinschen.de (vpn50-67.rdu.redhat.com [172.16.50.67]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id j0HEsWZZ011464 for ; Mon, 17 Jan 2005 09:54:33 -0500 Received: by cygbert.vinschen.de (Postfix, from userid 500) id 062B65808D; Mon, 17 Jan 2005 15:54:25 +0100 (CET) Date: Mon, 17 Jan 2005 14:54:00 -0000 From: Corinna Vinschen To: gdb-patches@sources.redhat.com Subject: [RFA] attach_command: clear solib state before attaching to process Message-ID: <20050117145425.GP3113@cygbert.vinschen.de> Reply-To: gdb-patches@sources.redhat.com Mail-Followup-To: gdb-patches@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-SW-Source: 2005-01/txt/msg00188.txt.bz2 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.