This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


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

Re: Another BFD corefile issue


Ian Lance Taylor wrote:
> 
>    From: "Michael Snyder" <msnyder@cygnus.com>
>    Date: Thu, 6 Apr 2000 20:03:20 -0700
> 
>    Also in elfcore.h, elf64_core_file_p may be called more than once from
>    bfd_check_format_matches.  If an earlier call matches, and a later call
>    ALMOST matches, it may clobber the earlier allocated pointer for
>    elf_obj_data.  I believe that the elf_zalloc call for elf_obj_data is done
>    too early, and I would like to move it down to just before it is actually
>    needed -- thus reducing the chance of it being called on a near-match.
> 
>    The circumstance where this bites us is when elf64-sparc target comes
>    before elf64-big.
> 
>    2000-04-06  Michael Snyder  <msnyder@seadog.cygnus.com>
> 
>            * elfcore.h (elf_core_file_p): delay allocating elf_obj_data
>            until it is needed, reducing the chances of memory leaks or
>            good data being clobbered unnecessarily.
> 
> There is no serious memory leak here, as anything allocated using
> bfd_zalloc will be freed when the BFD is closed.

The memory leak is secondary.  What happens is, an early call succeeds
and stores valuable data in the tdata field.  Then a later call clobbers
it via a new call to bfd_zalloc -- only to subsequently decide that this 
isn't a match.  So the data from the successful call is lost.
 
> However, if the format does not match, the function should bfd_release
> any tdata it has allocated.  See elf_object_p in elfcode.h.

That is what I'll do.  I'll publish a patch based on what elf_object_p
does later today.

Thanks,
Michael

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