leaks in lld on the bot

The asan bootstrap bot is unhappy with lld.
Rui, os someone, please take a look.


==26011==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 184 byte(s) in 1 object(s) allocated from:
    #0 0x72fab0 in operator new(unsigned long) /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:82
    #1 0x8c8610 in void lld::elf::BinaryFile::parse<llvm::object::ELFType<(llvm::support::endianness)1, true> >() /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/ELF/InputFiles.cpp:823:7
    #2 0xb9de74 in lld::elf::SymbolTable<llvm::object::ELFType<(llvm::support::endianness)1, true> >::addFile(lld::elf::InputFile*) /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/ELF/SymbolTable.cpp:61:8
    #3 0x82c46f in void lld::elf::LinkerDriver::link<llvm::object::ELFType<(llvm::support::endianness)1, true> >(llvm::opt::InputArgList&) /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/ELF/Driver.cpp:723:12
    #4 0x819578 in lld::elf::LinkerDriver::main(llvm::ArrayRef<char const*>, bool) /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/ELF/Driver.cpp:333:5
    #5 0x8174b8 in lld::elf::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&) /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/ELF/Driver.cpp:56:11
    #6 0x73432f in main /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/tools/lld/lld.cpp:104:13
    #7 0x7fc345503f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)

SUMMARY: AddressSanitizer: 184 byte(s) leaked in 1 allocation(s).


r286193 fixes the inlined failure. There are other 130 outstanding
failures, I'm taking a look at them now.

There are no more tests failing in ELF/. All the remaining failures
are in COFF, I'm not super-familiar with the code so I'll let someone
else fixing them.

Oh I want to point out that maybe these bugs open a case for switching
back to the old resource lifetime management (using unique_ptr<>)
instead of naked `new`. CC:ing dblaikie as he pointed out similar
issues in the post-commit review that did the switch. Rui, what do you

I don’t think unique _ptr (at least with the default deleter) is desirable as we do benefit from pool allocation.


I can't reproduce any more leaks with check-lld with asan.


I don't think unique _ptr (at least with the default deleter) is desirable
as we do benefit from pool allocation.

Sure, my aim is to have a less error-prone resource lifetime
management (and personally I think unique_ptr<> is an improvement over
naked `new`), but that's nowhere near the top of my list, and I agree with
you it requires more careful thinking. For now, happy that the bots are green =)