Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: Re: [RFA] elfread.c (elf_symtab_read): Stop memory leak.
Date: Tue, 03 May 2011 15:54:00 -0000	[thread overview]
Message-ID: <20110503155348.GA2528@adacore.com> (raw)
In-Reply-To: <20110307111540.GB30306@adacore.com>

> > 2011-03-05  Michael Snyder  <msnyder@vmware.com>
> > 
> > 	* 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


  parent reply	other threads:[~2011-05-03 15:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-05 20:35 Michael Snyder
2011-03-07 11:20 ` Joel Brobecker
2011-03-07 19:51   ` Michael Snyder
2011-05-03 15:54   ` Joel Brobecker [this message]
2011-05-03 16:28     ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110503155348.GA2528@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox