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