This is the mail archive of the gdb-patches@sourceware.org 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]
Other format: [Raw text]

Re: Synthetic symbol leak in in elf_x86_64_get_synthetic_symtab and elf_read_minimal_symbols


I can verify that the objdump example is fixed in HEAD, but I still get this leak with `valgrind --leak-check=full --show-leak-kinds=definite gdb ./hello`:

==18127== 300,438 bytes in 5 blocks are definitely lost in loss record 11,404 of 11,407
==18127==    at 0x4C2DE31: malloc (vg_replace_malloc.c:299)
==18127==    by 0x62F747: bfd_malloc (libbfd.c:193)
==18127==    by 0x62F941: bfd_zmalloc (libbfd.c:278)
==18127== by 0x649E14: elf_x86_64_get_synthetic_symtab (elf64-x86-64.c:6835) ==18127== by 0x2F1B9E: elf_read_minimal_symbols(objfile*, int, elfinfo const*) (elfread.c:1124) ==18127== by 0x2F1D7C: elf_symfile_read(objfile*, enum_flags<symfile_add_flag>) (elfread.c:1182) ==18127== by 0x563738: read_symbols(objfile*, enum_flags<symfile_add_flag>) (symfile.c:861) ==18127== by 0x563E55: syms_from_objfile_1(objfile*, section_addr_info*, enum_flags<symfile_add_flag>) (symfile.c:1062) ==18127== by 0x563EAC: syms_from_objfile(objfile*, section_addr_info*, enum_flags<symfile_add_flag>) (symfile.c:1078) ==18127== by 0x5641F7: symbol_file_add_with_addrs(bfd*, char const*, enum_flags<symfile_add_flag>, section_addr_info*, enum_flags<objfile_flag>, objfile*) (symfile.c:1177) ==18127== by 0x5644C1: symbol_file_add_from_bfd(bfd*, char const*, enum_flags<symfile_add_flag>, section_addr_info*, enum_flags<objfile_flag>, objfile*) (symfile.c:1268) ==18127== by 0x547B32: solib_read_symbols(so_list*, enum_flags<symfile_add_flag>) (solib.c:707)

On 08/11/2017 11:44 AM, H.J. Lu wrote:
On Fri, Aug 11, 2017 at 8:45 AM, Yao Qi <qiyaoltc@gmail.com> wrote:
On 17-08-11 08:30:21, H.J. Lu wrote:
We can only safely do this, but .name is leaked for x86_64.  Other
tools using bfd, like objdump, nm, and gprof may have this issue too.
I'll ask binutils people on asymbol allocation and de-allocation.

This is:

https://sourceware.org/bugzilla/show_bug.cgi?id=21943

I opened it :)

i386 and x86-64 get_synthetic_symtab don't know if @plt should
be added to symbol name for a PLT entry.  The first pass checks
if @plt is needed and extra space is allocated in the second pass.
We can assume @plt is needed and waste some space if it isn't.
Do you plan to fix it?

Done.



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