From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24403 invoked by alias); 24 Jan 2007 22:52:41 -0000 Received: (qmail 24391 invoked by uid 22791); 24 Jan 2007 22:52:40 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.170) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 24 Jan 2007 22:52:33 +0000 Received: by ug-out-1314.google.com with SMTP id 39so769886ugf for ; Wed, 24 Jan 2007 14:52:31 -0800 (PST) Received: by 10.67.22.2 with SMTP id z2mr1720803ugi.1169679151214; Wed, 24 Jan 2007 14:52:31 -0800 (PST) Received: from ?192.168.0.11? ( [82.229.199.15]) by mx.google.com with ESMTP id s7sm1787922uge.2007.01.24.14.52.30; Wed, 24 Jan 2007 14:52:30 -0800 (PST) Subject: Re: [RFC] varobj deletion after the binary has changed From: =?ISO-8859-1?Q?Fr=E9d=E9ric?= Riss To: Nick Roberts Cc: Denis PILAT , Vladimir Prus , gdb-patches@sources.redhat.com In-Reply-To: <17847.56114.220249.307621@kahikatea.snap.net.nz> 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> Content-Type: text/plain; charset=UTF-8 Date: Wed, 24 Jan 2007 22:52:00 -0000 Message-Id: <1169679148.5160.34.camel@funkylaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 8bit 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/msg00514.txt.bz2 Le jeudi 25 janvier 2007 à 11:18 +1300, Nick Roberts a écrit : > > Just a shot in the dark: did you test with a memory checker like > > valgrind? The fact that there's no crash doesn't mean that there's no > > buggy memory access. > > The execution proceeds as normal and correctly reports when a_global changes. > If there was a buggy memory access I presume it would manifest itself in the > execution of GDB in some way. You might be true. I mentioned that because it's easy to check and there seems to be no matching patch description in your spec file. Anyway fixing that seems simple enough that we don't need to dig through 80 RedHat patches to come up with a patch. AFAIK Denis's working on a version re-evealuating (actually re-parsing) varobjs with no attached blocks and putting the others in some error state that'll return in_scope="false" at the next update. Does that seem reasonable? Fred.