This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
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