[LLVMdev] [lld] memory leaks.

Rui Ueyama ruiu at google.com
Wed Nov 26 12:01:09 PST 2014


On Wed, Nov 26, 2014 at 9:16 AM, Jean-Daniel Dupas <devlists at shadowlab.org>
wrote:

> Hello,
>
> While working on lld code, I encountered a couple of memory management
> issues.
>
> If lld should be usable as a library, I assume it should not leaks any
> memory when performing a single link pass (UniversalDriver::link(arc,
> argv)).
>
> Actually, after calling that function, I got some major leaks. I may be
> wrong, but I think there is 3 major leaks.
>
> - One of the main leak is in FileArchive. When calling the find() method,
> FileArchive returns a non-owned pointer that is never deleted by the
> caller. The problem is that find() is a virtual method but does not
> properly define who is responsible of the returned pointer. So some
> implementations return a pointer to internal storage, and other
> implementation (FileArchive) returns a pointer without owner.
> Maybe a way to fix that issue is to tell that the pointer returned by
> find() must never be freed, and make sure the FileArchive (and other
> classes implementing find()) managed the memory of the returned file
> objects.
>
> - One other leak is Mach-O specific. TrieNode (in
> MachONormalizedFileBinaryWriter) uses a SmallVector to store its children.
> But TrieNodes are allocated using a llvm bumpPtr allocator, and so are
> never ‘deleted'. While the memory used by the TrieNode is properly released
> when the allocator is destroyed, the SmallVector destructor is never called
> and so the contained TrieEdges leak.
>
> - The third major leak source is the SimpleReferences stored in
> SimpleDefinedAtom (and subclasses). At least on Mach-O, MachODefinedAtoms
> are allocated using a llvm bumpPtr allocator, and so suffer the same issue
> than TrieNode. The SimpleDefinedAtom destructor is never called, and so the
> vector of SimpleReference defined in SimpleDefinedAtom is never deleted.
>
> Should I fill some bug report for theses leaks ?
>

Yes, please. All memory leaks need to be fixed.



>
> -- Jean-Daniel
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141126/953b1eb5/attachment.html>


More information about the llvm-dev mailing list