This is the mail archive of the
mailing list for the binutils project.
who owns a BFD coming from an archive?
- From: Tom Tromey <tromey at redhat dot com>
- To: Binutils Development <binutils at sourceware dot org>
- Date: Mon, 23 Jul 2012 14:11:33 -0600
- Subject: who owns a BFD coming from an archive?
As part of a gdb patch series I've been looking into how BFD treats
Suppose you have an archive BFD, opened with bfd_openr with a subsequent
successful call to bfd_check_format (archive, bfd_archive). Now suppose
you iterate over the members of the archive using
In this case, my experiments yield some weird results:
* For an ordinary archive, according to valgrind (and my reading of the
code, though I found it a bit hard to follow...), the caller is
expected to close each member BFD using bfd_close. If you don't call
bfd_close on each one, you get memory leaks.
However, there is a latent bug here. If the member is closed, it does
not notify the parent BFD, and so the archive cache (e.g.,
archive.c:_bfd_look_for_bfd_in_cache) refers to freed memory.
Also, the memory for the members' file names is allocated in memory
attached to the parent archive. So, if you close the parent archive,
bfd_get_filename on a member will yield a freed pointer.
* For a thin archive, again according to valgrind and my reading, the
opposite is true: the archive owns the BFDs, and if you close each
one, you will see crashes.
* Finally, nothing ever frees the hash table created by
My first question is -- is my analysis correct?
I think I got it all right, but perhaps I am missing something.
My second question is, anybody have a definitive opinion on the best way
to fix the problems?
I think it would be best for clients if both ordinary and thin archives
were treated in the same way.
For gdb's purposes I think it would be a little more convenient if an
archive and its members were independent, but I can make gdb work with
either ownership approach.
The cache poisoning and deletion problems seem relatively
straightforward to fix, though I'm probably not really conversant enough
with BFD to pick the right spot to hack.
For the filename problem, in gdb we recently adopted a rule to
(re-)allocate a BFD's file name using bfd_alloc. This ties the lifetime
of the filename to that of the BFD, usually what you want. So, one idea
here would be to promote this idea into BFD; but again, I don't really
care much, I would just like some guidance from you.
I'm happy to implement the desired fixes.