[LLVMdev] [lld] memory leaks.

[Harsh Vardhan Dwivedi]

Hi all,

 

Can lld be used as a library as well? Also, is it possible to dump the fully linked IR code of the final program along with the program binary? I know llvm-link can link the IR but can we embed llvm-link functionality in lld to automatically dump alongside object code, the full program IR as well?

 

Regards,

 

Harsh

 

 

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

 

 

 

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Rui Ueyama
Sent: Wednesday, November 26, 2014 1:01 PM
To: Jean-Daniel Dupas
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] [lld] memory leaks.

 

On Wed, Nov 26, 2014 at 9:16 AM, Jean-Daniel Dupas <devlists at shadowlab.org <mailto: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 <mailto: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/4b3aa42f/attachment.html>