From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8645 invoked by alias); 3 May 2011 15:54:10 -0000 Received: (qmail 8628 invoked by uid 22791); 3 May 2011 15:54:07 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_BJ,TW_DB,TW_YM X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 May 2011 15:53:54 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 531A02BAF62 for ; Tue, 3 May 2011 11:53:53 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZE-lnnGR-yRW for ; Tue, 3 May 2011 11:53:53 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 2585A2BAE59 for ; Tue, 3 May 2011 11:53:53 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id B70FA145615; Tue, 3 May 2011 08:53:48 -0700 (PDT) Date: Tue, 03 May 2011 15:54:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFA] elfread.c (elf_symtab_read): Stop memory leak. Message-ID: <20110503155348.GA2528@adacore.com> References: <4D729E84.3050401@vmware.com> <20110307111540.GB30306@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110307111540.GB30306@adacore.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2011-05/txt/msg00064.txt.bz2 > > 2011-03-05 Michael Snyder > > > > * elfread.c (elf_symtab_read): Stop memory leak. > > I think that's OK. A little more nervous than usual, as I had > to look through a fair bit of code. But you did run this change > past the testsuite, right? I'm going to revert this patch, because I don't think it's right. It's causing GDB to crash while loading symbols from ld.so on sparc-solaris. Reviewing the patch again, I can't understand what I was thinking when I reviewed it, because the data is referenced by the objfile, thusly: struct dbx_symfile_info *dbx = objfile->deprecated_sym_stab_info; [...] if (sectinfo != NULL) { sectinfo->next = dbx->stab_section_info; dbx->stab_section_info = sectinfo; sectinfo = NULL; } There may very well be a memory leak, but it's a lot less contained than Michael probably thought. I don't know the code well enough to really be sure how we'd be leaking, and risk a fix. Perhaps the sectinfo list should be released in: /* Perform any local cleanups required when we are done with a particular objfile. I.E, we are in the process of discarding all symbol information for an objfile, freeing up all memory held for it, and unlinking the objfile struct from the global list of known objfiles. */ static void elf_symfile_finish (struct objfile *objfile) { if (objfile->deprecated_sym_stab_info != NULL) { xfree (objfile->deprecated_sym_stab_info); } dwarf2_free_objfile (objfile); } A call to free_elfinfo before the call to xfree might do: /* This cleans up the objfile's deprecated_sym_stab_info pointer, and the chain of stab_section_info's, that might be dangling from it. */ static void free_elfinfo (void *objp) { -- Joel