bfd_preserve may cause memory leaks
Daniel Jacobowitz
drow@mvista.com
Sat Jan 18 04:12:00 GMT 2003
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
More information about the Binutils
mailing list