From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23266 invoked by alias); 17 Jan 2005 16:27:45 -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 23207 invoked from network); 17 Jan 2005 16:27:31 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 17 Jan 2005 16:27:31 -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 j0HGRVGD020608 for ; Mon, 17 Jan 2005 11:27:31 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0HGRVO02635 for ; Mon, 17 Jan 2005 11:27:31 -0500 Received: from localhost.localdomain (vpn50-74.rdu.redhat.com [172.16.50.74]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id j0HGRUqh006278; Mon, 17 Jan 2005 11:27:30 -0500 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with ESMTP id j0HGROlQ015228; Mon, 17 Jan 2005 09:27:24 -0700 Date: Mon, 17 Jan 2005 16:27:00 -0000 From: Kevin Buettner To: gdb-patches@sources.redhat.com Cc: vinschen@redhat.com Subject: Re: [RFA] attach_command: clear solib state before attaching to process Message-ID: <20050117092724.4ec11c82@ironwood.lan> In-Reply-To: <20050117145425.GP3113@cygbert.vinschen.de> References: <20050117145425.GP3113@cygbert.vinschen.de> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2005-01/txt/msg00190.txt.bz2 On Mon, 17 Jan 2005 15:54:25 +0100 Corinna Vinschen 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