From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24328 invoked by alias); 4 Sep 2009 21:18:11 -0000 Received: (qmail 24318 invoked by uid 22791); 4 Sep 2009 21:18:09 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,FB_WORD1_END_DOLLAR,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 Sep 2009 21:18:03 +0000 Received: from spaceape14.eur.corp.google.com (spaceape14.eur.corp.google.com [172.28.16.148]) by smtp-out.google.com with ESMTP id n84LI0F0019929 for ; Fri, 4 Sep 2009 14:18:01 -0700 Received: from ywh39 (ywh39.prod.google.com [10.192.8.39]) by spaceape14.eur.corp.google.com with ESMTP id n84LHveg010606 for ; Fri, 4 Sep 2009 14:17:58 -0700 Received: by ywh39 with SMTP id 39so2037508ywh.26 for ; Fri, 04 Sep 2009 14:17:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.115.1 with SMTP id s1mr9213736ybm.106.1252099077335; Fri, 04 Sep 2009 14:17:57 -0700 (PDT) Date: Fri, 04 Sep 2009 21:18:00 -0000 Message-ID: Subject: TYPE_NAME memory management From: Doug Evans To: Paul Pluzhnikov Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-IsSubscribed: yes 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/msg00087.txt.bz2 On Fri, Sep 4, 2009 at 11:03 AM, Doug Evans wrote: > On Fri, Sep 4, 2009 at 10:59 AM, Paul Pluzhnikov wrote: >> On Fri, Sep 4, 2009 at 8:25 AM, Paul Pluzhnikov wrote: >> >>> I am still working on a stand-alone repro case. >> >> Here it is: >> >>[...] >> Segmentation fault (core dumped) >> >> I will not be able to work on a fix before next Tuesday, so if anybody >> fixes this before then, please let me know. Memory management for TYPE_NAME and TYPE_TAG_NAME is a bit random. E.g. bash$ grep "TYPE_NAME *(.*) *= " *.c bash$ grep "TYPE_TAG_NAME *(.*) *= " *.c Sometimes it's a string constant, sometimes it's in malloc space, sometimes it's on objfile's obstack, and now sometimes it can live in mmap'd space. Obviously one would rather not place ordering constraints on objfile data cleanups. All the above uses are "ok" (modulo any memory leaks from malloc'd strings) except for the new mmap'd values, so it seems like the thing to do for now is copy such strings onto the objfile's obstack. I'm not sure what the speed loss will be, but I think it's the thing to do pending data that says something more clever is needed.