Valgrind; clang::ASTUnit::Parse -> lost memory?

Humm, when I run valgrind over my code I’m getting:

==30376== HEAP SUMMARY:
==30376== in use at exit: 1,928 bytes in 25 blocks
==30376== total heap usage: 28,193 allocs, 28,168 frees, 2,194,616 bytes allocated
==30376== 1,864 (1,056 direct, 808 indirect) bytes in 1 blocks are definitely lost in loss record 15 of 15
==30376== at 0x4C28973: operator new(unsigned long) (vg_replace_malloc.c:261)
==30376== by 0x57C7A62: clang::ASTUnit::Parse(llvm::MemoryBuffer*) (in /home/doug/projects/cparse/deps/llvm/build/lib/
==30376== by 0x57CB686: clang::ASTUnit::LoadFromCompilerInvocation(bool) (in /home/doug/projects/cparse/deps/llvm/build/lib/
==30376== by 0x57CBF0F: clang::ASTUnit::LoadFromCommandLine(char const**, char const**, llvm::IntrusiveRefCntPtrclang::DiagnosticsEngine, llvm::StringRef, bool, bool, std::pair<std::string, llvm::PointerUnion<char const*, llvm::MemoryBuffer const*> >, unsigned int, bool, bool, clang::TranslationUnitKind, bool, bool) (in /home/doug/projects/cparse/deps/llvm/build/lib/
==30376== by 0x54F5E14: clang_parseTranslationUnit_Impl (in /home/doug/projects/cparse/deps/llvm/build/lib/
==30376== by 0x5E3BD89: llvm::CrashRecoveryContext::RunSafely(void (
)(void*), void*) (in /home/doug/projects/cparse/deps/llvm/build/lib/
==30376== by 0x5E3BE90: RunSafelyOnThread_Dispatch(void*) (in /home/doug/projects/cparse/deps/llvm/build/lib/
==30376== by 0x5E72924: ExecuteOnThread_Dispatch(void*) (in /home/doug/projects/cparse/deps/llvm/build/lib/
==30376== by 0x6D82970: start_thread (pthread_create.c:304)
==30376== by 0x68DA92C: clone (clone.S:112)
==30376== LEAK SUMMARY:
==30376== definitely lost: 1,056 bytes in 1 blocks

I’m a little lost as to if this is something I’m doing wrong on my code, or some kind of clang internal thing (seems internal, but I wouldnt have expected clang to leak memory, so I suspect perhaps I’m not cleaning up correctly after use?).

Any suggestions how to track this down?

My code is roughly like:


Is there some other shutdown I need to run?

Hi Doug,

Can you provide a complete test file the exhibits the leak, that we can compile and investigate ?


Mm… a minimal test case; I’ll see if I can build one that replicates the issue; gonna need some heavy refactoring to make that happen though; perhaps over the weekend.

There was a memory leak fixed by Ted, please try again with latest clang.


Yes, this seems to be fixed on HEAD now;

==2588== LEAK SUMMARY:
==2588== definitely lost: 0 bytes in 0 blocks
==2588== indirectly lost: 0 bytes in 0 blocks
==2588== possibly lost: 0 bytes in 0 blocks
==2588== still reachable: 64 bytes in 3 blocks
==2588== suppressed: 0 bytes in 0 blocks