From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23440 invoked by alias); 25 Jan 2007 20:50:11 -0000 Received: (qmail 23427 invoked by uid 22791); 25 Jan 2007 20:50:10 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 25 Jan 2007 20:50:01 +0000 Received: from kahikatea.snap.net.nz (243.61.255.123.dynamic.snap.net.nz [123.255.61.243]) by viper.snap.net.nz (Postfix) with ESMTP id E3AB23D833C; Fri, 26 Jan 2007 09:49:52 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 4D72C4F71D; Fri, 26 Jan 2007 09:49:49 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17849.6124.750912.589862@kahikatea.snap.net.nz> Date: Thu, 25 Jan 2007 20:50:00 -0000 To: Daniel Jacobowitz Cc: =?iso-8859-1?Q?Fr=E9d=E9ric?= Riss , Denis PILAT , Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: [RFC] varobj deletion after the binary has changed In-Reply-To: <20070125024118.GA10014@nevyn.them.org> References: <45B60056.6030704@st.com> <20070123124457.GA1600@nevyn.them.org> <45B61B41.90509@st.com> <17847.54349.654238.452957@kahikatea.snap.net.nz> <1169676493.5160.14.camel@funkylaptop> <17847.56114.220249.307621@kahikatea.snap.net.nz> <20070125024118.GA10014@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.93.1 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00524.txt.bz2 > > If there was a buggy memory access I presume it would manifest itself in > > the execution of GDB in some way. > > No, that's a bad assumption to make about invalid memory access. It's > often impossible to detect it without some luck or a tool like > valgrind. It even identifies the variable object as int: -var-info-type var1 ^done,type="int" (gdb) which would seem a remarkable coincidence if it was looking at the wrong address. I'm not sure what happens on rereading, maybe space gets malloced for the symbol table, freed and then malloced again. Perhaps with FC5 it's just fortunate that the symbol table is allocated exactly as before. In any case, it can segfault if you edit the source file and recompile before (re)starting execution, so some change is necessary. -- Nick http://www.inet.net.nz/~nickrob