From: Daniel Jacobowitz <drow@mvista.com>
To: gdb-patches@sources.redhat.com
Subject: Re: RFA: Fix a big memory leak reading minimal symbols
Date: Thu, 20 Feb 2003 19:32:00 -0000 [thread overview]
Message-ID: <20030220192230.GA18821@nevyn.them.org> (raw)
In-Reply-To: <15955.62999.412522.284136@localhost.redhat.com>
On Wed, Feb 19, 2003 at 04:24:39PM -0500, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
> > On Wed, Feb 05, 2003 at 02:35:27PM -0500, Elena Zannoni wrote:
> > > Daniel Jacobowitz writes:
> > > > This patch is good for a whopping 13% (7MB) of memory usage when reading in
> > > > all of mozilla's minimal symbols (stabs). The control flow looks like this
> > > > right now:
> > > > - init_minimal_symbol_collection in elf_symfile_read
> > > > - install_minimal_symbols in elfstab_build_psymtabs. Presumably added so
> > > > that we don't lose the minimal symbols above.
> > >
> > > right, elfstab_build_psymtab is called by elf_symfile_read, after
> > > init_minimal_symbol_collection.
> > >
> > > > - dbx_symfile_read contains a complete init_minimal_symbol_collection /
> > > > install_minimal_symbols pair, which generally finds no minimal symbols
> > > > in ELF.
> > >
> > > elfstab_build_psymtab calls dbx_symfile_read.
> > >
> > > > - install_minimal_symbols and matching cleanup in elf_symfile_read.
> > > >
> > >
> > > at the end.
> > >
> > > > Only problem is, that second init_minimal_symbol_collection call zeroed out
> > > > the bunch pointer. We've installed them but we never free them, so they
> > > > just sit around wasting memory.
> > >
> > > OK, I see the problem in this sequence. There is another 'stray' call
> > > to install_minimal_symbols, in stabsect_build_psymtab, and this
> > > function also calls dbx_symfile_read. The sequence is the same. So the
> > > problem should occur there as well.
> > > stabsect_build_psymtab is called by som_symfile_read.
> >
> > And by nlm_symfile_read too.
> >
> > > > This patch arranges for all calls to init_minimal_symbol_collection in ELF
> > > > targets to be paired with matching cleanups and install_minimal_symbols
> > > > calls. This means that elfmdebug_build_psymtabs gets its own pair instead
> > > > of relying on elf_symfile_read, and that elf_symfile_read installs its own
> > > > minimal symbols much earlier.
> > >
> > > How does elfstab_build_psymtabs get invoked from mdebug? Oh, it
> > > doesn't. It gets invoked after the mdebug stuff is over.
> > >
> > > I see, you are adding pairs of install+cleanup to the mdebug psymtab
> > > builder, i.e. each piece is self-sufficient. For the stabs psymtab
> > > builder the appropriate steps are done in dbx_symfile_read already.
> >
> > Right. Each reader that wants to do this, should do it itself, since
> > they don't nest.
> >
> > > let's see all the symtabs builders:
> > >
> > > coffstab_build_psymtabs -> calls dbx_symfile_read ok
> >
> > Ugh. This is OK but its caller isn't; coff_symtab_read has some
> > minimal symbols outstanding when it calls coffstab_build_psymtabs.
> > Fixed, but I don't have any tests for COFF set up.
> >
> > > elfstab_build_psymtabs -> you fixed ok
> > > stabsect_build_psymtabs -> dubious
> >
> > Fixed, in both callers.
> >
> > > dwarf2_build_psymtabs -> no need
> > > dwarf_build_psymtabs -> don't care
> > > hpread_build_psymtabs -> no clue, messy. I think it does it directly.
> > > mdebug_build_psymtabs -> you fixed ok
> > >
> > > if the table above makes sense, then can you verify/fix the dubious case?
> >
> > How's this look? New changes in coff_symfile_read, nlm_symfile_read,
> > som_symfile_read, and stabsect_build_psymtabs.
> >
>
> Okey
Thanks, I've checked it in! One more off the list.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
prev parent reply other threads:[~2003-02-20 19:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-26 19:13 Daniel Jacobowitz
2003-02-05 19:31 ` Elena Zannoni
2003-02-05 22:26 ` Daniel Jacobowitz
2003-02-19 21:20 ` Elena Zannoni
2003-02-20 19:32 ` Daniel Jacobowitz [this message]
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=20030220192230.GA18821@nevyn.them.org \
--to=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
/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