[cfe-dev] Running clang with valgrind.

Eli Friedman eli.friedman at gmail.com
Mon Oct 31 12:03:13 PDT 2011


On Mon, Oct 31, 2011 at 11:32 AM, Andrey Tarasevich
<tarasevich.andrey at googlemail.com> wrote:
> Hi!
>
> I'm using clang as a parser. I'm doing at the moment one simple thing.
> I'm collecting function names from the files. I run clang on set of
> the files from the Linux Kernel, i.e. <linux_kernel_folder>/kernel/
> Although I'm calling llvm::llvm_shutdown(); after I finished with the
> file processing, I get memory leak and seems to be it is not my code,
> but I'm still investigating it.
>
> I profiled program run with Valgrind and I received following results.
>
> ==18386== 65,536 bytes in 16 blocks are possibly lost in loss record 15 of 24
> ==18386==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
> ==18386==    by 0x9F985B: llvm::MallocSlabAllocator::Allocate(unsigned
> long) (in /home/sevich/src/Debug/master)
> ==18386==    by 0x9F95B3: llvm::BumpPtrAllocator::StartNewSlab() (in
> /home/sevich/src/Debug/master)
> ==18386==    by 0x9F9814: llvm::BumpPtrAllocator::Allocate(unsigned
> long, unsigned long) (in /home/sevich/src/Debug/master)
> ==18386==    by 0x8025C9: llvm::StringMap<clang::TypoCorrection,
> llvm::BumpPtrAllocator>::GetOrCreateValue(llvm::StringRef) (in
> /home/sevich/src/Debug/master)
> ==18386==    by 0x7F3CAE: (anonymous
> namespace)::TypoCorrectionConsumer::addCorrection(clang::TypoCorrection)
> (in /home/sevich/src/Debug/master)
> ==18386==    by 0x7F40A3: (anonymous
> namespace)::TypoCorrectionConsumer::addName(llvm::StringRef,
> clang::NamedDecl*, unsigned int, clang::NestedNameSpecifier*, bool)
> (in /home/sevich/src/Debug/master)
> ==18386==    by 0x7F423D: (anonymous
> namespace)::TypoCorrectionConsumer::FoundName(llvm::StringRef) (in
> /home/sevich/src/Debug/master)
> ==18386==    by 0x7FF21B:
> clang::Sema::CorrectTypo(clang::DeclarationNameInfo const&,
> clang::Sema::LookupNameKind, clang::Scope*, clang::CXXScopeSpec*,
> clang::DeclContext*, bool, clang::Sema::CorrectTypoContext,
> clang::ObjCObjectPointerType const*) (in
> /home/sevich/src/Debug/master)
> ==18386==    by 0x6E37A5:
> clang::Sema::DiagnoseUnknownTypeName(clang::IdentifierInfo const&,
> clang::SourceLocation, clang::Scope*, clang::CXXScopeSpec*,
> clang::OpaquePtr<clang::QualType>&) (in /home/sevich/src/Debug/master)
> ==18386==    by 0x6288B9:
> clang::Parser::ParseImplicitInt(clang::DeclSpec&,
> clang::CXXScopeSpec*, clang::Parser::ParsedTemplateInfo const&,
> clang::AccessSpecifier) (in /home/sevich/src/Debug/master)
> ==18386==    by 0x624B19:
> clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
> clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
> clang::Parser::DeclSpecContext) (in /home/sevich/src/Debug/master)
> ==18386==
> ==18386== 27,126,048 (486,080 direct, 26,639,968 indirect) bytes in
> 6,076 blocks are definitely lost in loss record 24 of 24
> ==18386==    at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261)
> ==18386==    by 0x7F3EF2: (anonymous
> namespace)::TypoCorrectionConsumer::addCorrection(clang::TypoCorrection)
> (in /home/sevich/src/Debug/master)
> ==18386==    by 0x7F40A3: (anonymous
> namespace)::TypoCorrectionConsumer::addName(llvm::StringRef,
> clang::NamedDecl*, unsigned int, clang::NestedNameSpecifier*, bool)
> (in /home/sevich/src/Debug/master)
> ==18386==    by 0x7F423D: (anonymous
> namespace)::TypoCorrectionConsumer::FoundName(llvm::StringRef) (in
> /home/sevich/src/Debug/master)
> ==18386==    by 0x7FF21B:
> clang::Sema::CorrectTypo(clang::DeclarationNameInfo const&,
> clang::Sema::LookupNameKind, clang::Scope*, clang::CXXScopeSpec*,
> clang::DeclContext*, bool, clang::Sema::CorrectTypoContext,
> clang::ObjCObjectPointerType const*) (in
> /home/sevich/src/Debug/master)
> ==18386==    by 0x6FD184: clang::Sema::ClassifyName(clang::Scope*,
> clang::CXXScopeSpec&, clang::IdentifierInfo*&, clang::SourceLocation,
> clang::Token const&) (in /home/sevich/src/Debug/master)
> ==18386==    by 0x5FD1A7:
> clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
> 32u>&, bool) (in /home/sevich/src/Debug/master)
> ==18386==    by 0x5FAAED:
> clang::Parser::ParseCompoundStatementBody(bool) (in
> /home/sevich/src/Debug/master)
> ==18386==    by 0x5FB22C:
> clang::Parser::ParseCompoundStatement(clang::ParsedAttributes&, bool,
> unsigned int) (in /home/sevich/src/Debug/master)
> ==18386==    by 0x5FB280:
> clang::Parser::ParseCompoundStatement(clang::ParsedAttributes&, bool)
> (in /home/sevich/src/Debug/master)
> ==18386==    by 0x5FD4D9:
> clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
> 32u>&, bool) (in /home/sevich/src/Debug/master)
> ==18386==    by 0x60029E:
> clang::Parser::ParseWhileStatement(clang::ParsedAttributes&) (in
> /home/sevich/src/Debug/master)
>
> Is this really a memory leak or I'm missing something?

You shouldn't have to do anything special to clean up the memory in
question, so likely a bug.

-Eli




More information about the cfe-dev mailing list