Re: memory leak in bfd_find_nearest_line()

[Ondrej Certik <ondrej at certik dot cz>]

On Fri, Sep 24, 2010 at 5:51 PM, Ondrej Certik <ondrej@certik.cz> wrote:
> Hi,
>
> I am having a weird leak in bfd_find_nearest_line() if I use the
> binutils 2.20.1-3ubuntu7 package, but if I download the sources for
> this package, build bfd myself and use it (either statically or
> dynamically), the leak disappears. How can that be possible?
>
> You can try it yourself by doing:
>
> git clone git://github.com/certik/rcp.git
> cd rcp
> cmake .
> make
> examples/test_memory/test_memory
>
> then run "top" in another terminal and observer that the memory usage
> is growing (the test_memory program calls bfd_openr(),
> bfd_find_nearest_line(), bfd_close() in an infinite loop).
>
> Valgrind complains about 20 things roughly, one of them is:
>
> ==300== 4,064 bytes in 1 blocks are possibly lost in loss record 15 of 21
> ==300== Â Âat 0x4C284A8: malloc (vg_replace_malloc.c:236)
> ==300== Â Âby 0x50FA3CC: objalloc_create (in
> /usr/lib/libbfd-2.20.1-system.20100303.so)
> ==300== Â Âby 0x50832C8: bfd_hash_table_init_n (in
> /usr/lib/libbfd-2.20.1-system.20100303.so)
> ==300== Â Âby 0x50781B1: bfd_preserve_save (in
> /usr/lib/libbfd-2.20.1-system.20100303.so)
> ==300== Â Âby 0x5099E18: bfd_elf64_object_p (in
> /usr/lib/libbfd-2.20.1-system.20100303.so)
> ==300== Â Âby 0x507D651: bfd_check_format_matches (in
> /usr/lib/libbfd-2.20.1-system.20100303.so)
> ==300== Â Âby 0x5090FC6: ??? (in /usr/lib/libbfd-2.20.1-system.20100303.so)
> ==300== Â Âby 0x5091106: _bfd_dwarf2_find_nearest_line (in
> /usr/lib/libbfd-2.20.1-system.20100303.so)
> ==300== Â Âby 0x509D0B9: _bfd_elf_find_nearest_line (in
> /usr/lib/libbfd-2.20.1-system.20100303.so)
> ==300== Â Âby 0x4E40C2B: (anonymous namespace)::process_section(bfd*,
> bfd_section*, void*) (Teuchos_stacktrace.cpp:226)
> ==300== Â Âby 0x50811CB: bfd_map_over_sections (in
> /usr/lib/libbfd-2.20.1-system.20100303.so)
>
> I was able to find the definitions of all the functions above, except
> bfd_elf64_object_p, but I am not sure from the source code what is
> happening, and why it doesn't get deallocated.

I have recompiled the Ubuntu package without stripping the
/usr/lib/libbfd-2.20.1-system.20100303.so, and I get the following
stacktrace:


==10743== 4,064 bytes in 1 blocks are possibly lost in loss record 15 of 21
==10743==    at 0x4C284A8: malloc (vg_replace_malloc.c:236)
==10743==    by 0x50FA3CC: objalloc_create (objalloc.c:95)
==10743==    by 0x50832C8: bfd_hash_table_init_n (hash.c:371)
==10743==    by 0x50781B1: bfd_preserve_save (bfd.c:1624)
==10743==    by 0x5099E18: bfd_elf64_object_p (elfcode.h:542)
==10743==    by 0x507D651: bfd_check_format_matches (format.c:211)
==10743==    by 0x5090FC6: find_line (dwarf2.c:2897)
==10743==    by 0x5091106: _bfd_dwarf2_find_nearest_line (dwarf2.c:3189)
==10743==    by 0x509D0B9: _bfd_elf_find_nearest_line (elf.c:7183)
==10743==    by 0x4E40C2B: (anonymous
namespace)::process_section(bfd*, bfd_section*, void*)
(Teuchos_stacktrace.cpp:226)
==10743==    by 0x50811CB: bfd_map_over_sections (section.c:1250)
==10743==    by 0x4E410A5: (anonymous
namespace)::addr2str(std::string, unsigned long)
(Teuchos_stacktrace.cpp:301)


so at least I know what exactly causes it, by simply going into the
files+line numbers noted above. But unfortunately I don't understand
the bfd code enough to see why it doesn't get deallocated.

Another interesting thing is that when I copy the exact source code
(including all Ubuntu patches) and recompile it myself using:

cd binutils-2.20.1/bfd/
CFLAGS="-g -fPIC" ./configure
make -j3
gcc -shared -o libbfd-d.so *.o

and then link it with my application (see my previous email), I don't
get any leaks nor valgrind warnings. This leads me to the conclusion
that

1) Ubuntu patches probably don't cause it (as I tried to compile bfd
myself both with and without the custom Ubuntu patches, and I never
got a leak)
2) It must be something related to the compilation/linking of the bfd
package. I also tried to compile it with:

cd binutils-2.20.1
CFLAGS="-g -fPIC" ./configure --enable-shared --prefix=`pwd`/../tmp/usr
make -j3
make install

and it still doesn't leak. So I will try to take it to the Ubuntu
guys, because it must be something happening during the
configuring/compilation of the package.

Ondrej