[LLVMdev] Memory leaks in LLVM on linux

Villmow, Micah Micah.Villmow at amd.com
Fri Jan 13 10:08:47 PST 2012


I am trying to figure out how to free up some memory that seems to be lost when running valgrind under our internal application. The stack traces I get are:
==19966== 4 bytes in 1 blocks are still reachable in loss record 1 of 12
==19966==    at 0x402569A: operator new(unsigned int) (vg_replace_malloc.c:255)
==19966==    by 0x5D9BBE8: void* llvm::object_creator<llvm::PassRegistry>()
(ManagedStatic.h:25)
==19966==    by 0x5E05AB6: llvm::ManagedStaticBase::RegisterManagedStatic(void*
(*)(), void (*)(void*)) const (ManagedStatic.cpp:47)
==19966==    by 0x5D9B73E: llvm::ManagedStatic<llvm::PassRegistry>::operator*()
(ManagedStatic.h:67)
==19966==    by 0x5D997E1: llvm::PassRegistry::getPassRegistry()
(PassRegistry.cpp:34)
==19966==    by 0x5D86960:
llvm::PassRegistrationListener::~PassRegistrationListener() (Pass.cpp:227)
==19966==    by 0x5D86A39: llvm::PassNameParser::~PassNameParser()
(Pass.cpp:237)
==19966==    by 0x5D948A5: llvm::cl::list<llvm::PassInfo const*, bool,
llvm::PassNameParser>::~list() (CommandLine.h:1010)
==19966==    by 0x5D88E61: __tcf_2 (PassManager.cpp:69)
==19966==    by 0x660A587: __cxa_finalize (cxa_finalize.c:56)
==19966==    by 0x4A8D842: ??? (in
/home/mvillmow/Source/stg/opencl/drivers/opencl/dist/linux/debug/lib/x86/libamdoclcl32.so)
==19966==    by 0x5E2F85B: ??? (in
/home/mvillmow/Source/stg/opencl/drivers/opencl/dist/linux/debug/lib/x86/libamdoclcl32.so)
==19966==
==19966== 12 bytes in 1 blocks are still reachable in loss record 2 of 12
==19966==    at 0x402569A: operator new(unsigned int) (vg_replace_malloc.c:255)
==19966==    by 0x5660DA0: void*
llvm::object_creator<llvm::sys::SmartMutex<true> >() (ManagedStatic.h:25)
==19966==    by 0x5E05AB6: llvm::ManagedStaticBase::RegisterManagedStatic(void*
(*)(), void (*)(void*)) const (ManagedStatic.cpp:47)
==19966==    by 0x566056A: llvm::ManagedStatic<llvm::sys::SmartMutex<true>
>::operator*() (ManagedStatic.h:67)
==19966==    by 0x5D9984C:
llvm::PassRegistry::removeRegistrationListener(llvm::PassRegistrationListener*)
(PassRegistry.cpp:194)
==19966==    by 0x5D86971:
llvm::PassRegistrationListener::~PassRegistrationListener() (Pass.cpp:227)
==19966==    by 0x5D86A39: llvm::PassNameParser::~PassNameParser()
(Pass.cpp:237)
==19966==    by 0x5D948A5: llvm::cl::list<llvm::PassInfo const*, bool,
llvm::PassNameParser>::~list() (CommandLine.h:1010)
==19966==    by 0x5D88E61: __tcf_2 (PassManager.cpp:69)
==19966==    by 0x660A587: __cxa_finalize (cxa_finalize.c:56)
==19966==    by 0x4A8D842: ??? (in
/home/mvillmow/Source/stg/opencl/drivers/opencl/dist/linux/debug/lib/x86/libamdoclcl32.so)
==19966==    by 0x5E2F85B: ??? (in
/home/mvillmow/Source/stg/opencl/drivers/opencl/dist/linux/debug/lib/x86/libamdoclcl32.so)
==19966==
==19966== 24 bytes in 1 blocks are still reachable in loss record 3 of 12
==19966==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
==19966==    by 0x5E0741A: llvm::sys::MutexImpl::MutexImpl(bool) (Mutex.cpp:65)
==19966==    by 0x5660D66: llvm::sys::SmartMutex<true>::SmartMutex(bool)
(Mutex.h:93)
==19966==    by 0x5660DB2: void*
llvm::object_creator<llvm::sys::SmartMutex<true> >() (ManagedStatic.h:25)
==19966==    by 0x5E05AB6: llvm::ManagedStaticBase::RegisterManagedStatic(void*
(*)(), void (*)(void*)) const (ManagedStatic.cpp:47)
==19966==    by 0x566056A: llvm::ManagedStatic<llvm::sys::SmartMutex<true>
>::operator*() (ManagedStatic.h:67)
==19966==    by 0x5D9984C:
llvm::PassRegistry::removeRegistrationListener(llvm::PassRegistrationListener*)
(PassRegistry.cpp:194)
==19966==    by 0x5D86971:
llvm::PassRegistrationListener::~PassRegistrationListener() (Pass.cpp:227)
==19966==    by 0x5D86A39: llvm::PassNameParser::~PassNameParser()
(Pass.cpp:237)
==19966==    by 0x5D948A5: llvm::cl::list<llvm::PassInfo const*, bool,
llvm::PassNameParser>::~list() (CommandLine.h:1010)
==19966==    by 0x5D88E61: __tcf_2 (PassManager.cpp:69)
==19966==    by 0x660A587: __cxa_finalize (cxa_finalize.c:56)


Are these known issues? If so, how do I free this memory?

Thanks,
Micah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120113/f739bba5/attachment.html>


More information about the llvm-dev mailing list