Re: Synthetic symbol leak in in elf_x86_64_get_synthetic_symtab and elf_read_minimal_symbols

[Alex Lindsay <alexlindsay239@gmail.com>]

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