This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

who owns a BFD coming from an archive?


As part of a gdb patch series I've been looking into how BFD treats
archive members.

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
bfd_openr_next_archived_file.

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
  _bfd_add_bfd_to_archive_cache.


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.

thanks,
Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]