Re: bfd_preserve may cause memory leaks

[Daniel Jacobowitz <drow at mvista dot com>]

On Fri, Jan 17, 2003 at 07:56:15PM -0800, Felix Lee wrote:
> bfd_preserve is a mechanism used to save/restore the state
> of a bfd while sniffing a file, and I think it's going to
> cause memory leaks.  does anyone care?  I don't think it's
> an issue for binutils, since most of those programs finish
> relatively quickly.  it might be an issue for gdb if someone
> uses the same gdb process for multiple debugging sessions,
> eg, treating gdb more like an application than a utility.
> 
> fixing this is non-trivial.  the problem is the interface
> between bfd_check_format_matches() and the _check_format()
> method for a bfd_target.  most _check_format() methods kind
> of assume that if they succeed, then that's what bfd_target
> the bfd will be forever.  bfd_check_format_matches() kinda
> assumes that you can arbitrarily change what bfd_target the
> bfd is, without any bad effects.
> 
> the fix is to consistently choose one view or the other, and
> both options look like they'll require non-trivial changes.

bfd_preserve is the least of our worries.

When reading an ELF file, we:

 - Properly free the memory containing the vector of symbol pointers
 - Leak the memory containing the _SYMBOLS_ (this won't show up to a
   leak debugger; nothing does, because of obstacks).
 - Load the string table etc., which aren't leaked precisely, but are
   no longer needed afterwards and we have no way to discard.

I estimate that we lose something like 10% of our memory usage to this. 
For large files, that really sucks.  I'm still trying to figure out
what to do; the first leak is easy, with a change to the semantics of
bfd_get_symtab_upper_bound / bfd_get_dynamic_symtab_upper_bound, but
the others are harder.

BFD likes to use bfd_alloc for this sort of thing, which is a royal
pain when you want to get rid of it later!

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer