From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4339 invoked by alias); 4 Jan 2006 17:48:30 -0000 Received: (qmail 4332 invoked by uid 22791); 4 Jan 2006 17:48:30 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-01.spheriq.net (HELO lon-del-01.spheriq.net) (195.46.50.97) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Jan 2006 17:48:28 +0000 Received: from lon-out-02.spheriq.net ([195.46.50.130]) by lon-del-01.spheriq.net with ESMTP id k04HmJnF016140 for ; Wed, 4 Jan 2006 17:48:19 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-02.spheriq.net with ESMTP id k04HmHLw011552 for ; Wed, 4 Jan 2006 17:48:18 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id k04HmC9v027546 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 4 Jan 2006 17:48:17 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 56B40DA44; Wed, 4 Jan 2006 17:47:41 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 6679B47CB6; Wed, 4 Jan 2006 17:31:22 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id CC76C75995; Wed, 4 Jan 2006 17:31:21 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 6318048824; Wed, 4 Jan 2006 17:26:20 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CHC51237 (AUTH stubbsa); Wed, 4 Jan 2006 17:22:57 GMT Message-ID: <43BC03FB.9050209@st.com> Date: Wed, 04 Jan 2006 17:48:00 -0000 From: Andrew STUBBS User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Jim Blandy Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [RFC] Alternate approach to keeping convenience variables 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> In-Reply-To: <8f2776cb0601040900t6e821db5v96a2cd0ef35c53f0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.2.0 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/msg00043.txt.bz2 Jim Blandy wrote: > On 1/4/06, Andrew STUBBS wrote: > >>One point though - why is it ok to leak the memory? This seems like bad >>practice to me - I mean, types can be arbitrarily large and, even if >>they are typically small, the variables may be rewritten many many times >>(particularly by scripts with loops). Are you saying that they will be >>actually leaked or just left for some sort of garbage collection? > > > No, it'll really be leaked. But the leakage only occurs when symbol > files get unloaded from memory, so it would only affect scripts that > load and unload symbol files in a loop. I agree it's not optimal, but > I think the alternative is GC. > > Maybe we should think about that. Has anyone ever tried running GDB > using the Boehm collector's replacements for malloc and free? > 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.