From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12015 invoked by alias); 22 Jan 2006 21:04:11 -0000 Received: (qmail 11997 invoked by uid 22791); 22 Jan 2006 21:04:10 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sun, 22 Jan 2006 21:04:06 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F0mNV-0007nd-Tk; Sun, 22 Jan 2006 16:04:01 -0500 Date: Sun, 22 Jan 2006 21:04:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Andrew STUBBS , gdb-patches@sources.redhat.com Subject: Re: [RFC] Alternate approach to keeping convenience variables Message-ID: <20060122210401.GG27224@nevyn.them.org> Mail-Followup-To: Jim Blandy , Andrew STUBBS , gdb-patches@sources.redhat.com References: <4381DC75.80800@st.com> <8f2776cb0511212138g2adef40cr1632365c00e3bebc@mail.gmail.com> <43835114.5060401@st.com> <20051209205923.GA21331@nevyn.them.org> <43BBBBC3.1010201@st.com> <8f2776cb0601040900t6e821db5v96a2cd0ef35c53f0@mail.gmail.com> <43BC03FB.9050209@st.com> <8f2776cb0601041037i3993da95te76e1d9daa86a23c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f2776cb0601041037i3993da95te76e1d9daa86a23c@mail.gmail.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00309.txt.bz2 On Wed, Jan 04, 2006 at 10:37:06AM -0800, Jim Blandy wrote: > On 1/4/06, Andrew STUBBS wrote: > > Perhaps you could modify copy_type_recursive such that it creates a > > cleanup chain specific to the internal variable. Then call do cleanups > > in set_internal_var. > > > > Might be tricky with shared type copies though. Just a thought. > > Exactly. > > You can keep throwing complexity into the code to deal with this stuff > until it buries you. And it'll never be a full solution. Or it'll be > complete until someone wants to add some perfectly reasonable feature > (just as is happening with "let's preserve the values of convenience > variables across symfile loads" right now). At some point, we have to > take a step back and think about a complete solution. Right. For now, I'm OK with saying "this is a small memory leak when symbol files are unloaded". If someone wants to investigate adding boehm-gc to GDB and using that, instead, then I'm OK with that too :-) Every once in a while I do get the urge to go through GDB with a leak checker. But not often enough to jump through huge, rarely tested hoops for that case. -- Daniel Jacobowitz CodeSourcery