From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13937 invoked by alias); 4 Sep 2009 22:42:03 -0000 Received: (qmail 13928 invoked by uid 22791); 4 Sep 2009 22:42:03 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 Sep 2009 22:41:57 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n84Mfqtq001763; Fri, 4 Sep 2009 18:41:52 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n84MfpMk027646; Fri, 4 Sep 2009 18:41:51 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n84Mfork025151; Fri, 4 Sep 2009 18:41:51 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 350C6378242; Fri, 4 Sep 2009 16:41:50 -0600 (MDT) From: Tom Tromey To: Doug Evans Cc: Paul Pluzhnikov , gdb@sourceware.org Subject: Re: TYPE_NAME memory management References: Reply-To: tromey@redhat.com Date: Fri, 04 Sep 2009 22:42:00 -0000 In-Reply-To: (Doug Evans's message of "Fri, 4 Sep 2009 14:17:57 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00094.txt.bz2 >>>>> "Doug" == Doug Evans writes: Doug> Memory management for TYPE_NAME and TYPE_TAG_NAME is a bit random. Doug> Sometimes it's a string constant, sometimes it's in malloc space, Doug> sometimes it's on objfile's obstack, and now sometimes it can live in Doug> mmap'd space. Doug> Obviously one would rather not place ordering constraints on objfile Doug> data cleanups. All the above uses are "ok" (modulo any memory leaks Doug> from malloc'd strings) except for the new mmap'd values, so it seems Doug> like the thing to do for now is copy such strings onto the objfile's Doug> obstack. Doug> I'm not sure what the speed loss will be, but I think it's the thing Doug> to do pending data that says something more clever is needed. My understanding is that in the past the rule was that if a type had an objfile, then the type name could come directly from the debuginfo (allocated on the objfile's obstack), because GDB made a guarantee about the relative lifetimes of these objects. In particular, types were copied by preserve_one_value at a point where the string data was still live. Why can't we maintain that guarantee for mmap'd debuginfo as well? I realize that having a lot of lifetime dependencies can be tricky. But, this one is fairly well established already. For objfile-less types, I suspect we ought to always malloc any associated strings. That will let us avoid memory leaks once the type GC work is completed. (Currently I don't think we ever free such types.) Tom