[LLVMdev] [lld] memory leaks.

[Jean-Daniel Dupas]

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 ?

-- Jean-Daniel