Valgrind and gROOT class.. suppression file?

Hello Guys,

I hope I choose the right category for my issue!
I use compiled ROOT6 (git commit: 90db6c66e8d43f9f9654c66ecb8f6d6f74856fd1) and the following code :

#include <TApplication.h>
#include <Riostream.h>
#include <TLorentzVector.h>
#include <TTree.h>
#include <TLegend.h>
#include <TFile.h>
#include <TKey.h>
#include <TH1.h>
#include <TH2.h>
#include <TH3.h>
#include <TGraph.h>
#include <TCanvas.h>
#include <TStyle.h>
#include <TSystem.h>
#include <TEntryList.h>
#include <TROOT.h>
#include <TClass.h>

using namespace std;

int main(int argc, char **argv)
{
     cout << gROOT << endl;
}

While looking for memory leak, I ended up with the following outgoing message:

==10148== Memcheck, a memory error detector
==10148== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==10148== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==10148== Command: LsRoot output-dy15W07t5.root
==10148== 
0x54cce00
==10148== 
==10148== HEAP SUMMARY:
==10148==     in use at exit: 24,972,109 bytes in 35,597 blocks
==10148==   total heap usage: 81,352 allocs, 45,755 frees, 48,298,561 bytes allocated
==10148== 
==10148== 32 bytes in 1 blocks are possibly lost in loss record 883 of 3,056
==10148==    at 0x4C3017F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10148==    by 0xA4C0023: llvm::MDTuple::getImpl(llvm::LLVMContext&, llvm::ArrayRef<llvm::Metadata*>, llvm::Metadata::StorageType, bool) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x854BDBB: clang::CodeGen::CodeGenModule::Release() (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x848EDD6: clang::CodeGeneratorImpl::HandleTranslationUnit(clang::ASTContext&) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x8422236: cling::IncrementalParser::codeGenTransaction(cling::Transaction*) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x84225DC: cling::IncrementalParser::commitTransaction(llvm::PointerIntPair<cling::Transaction*, 2u, cling::IncrementalParser::EParseResult, llvm::PointerLikeTypeTraits<cling::Transaction*>, llvm::PointerIntPairInfo<cling::Transaction*, 2u, llvm::PointerLikeTypeTraits<cling::Transaction*> > >&, bool) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x83ADB67: cling::Interpreter::Interpreter(int, char const* const*, char const*, bool, cling::Interpreter const*) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x831966B: Interpreter (Interpreter.h:317)
==10148==    by 0x831966B: TCling::TCling(char const*, char const*, char const* const*) (TCling.cxx:1269)
==10148==    by 0x831AE93: CreateInterpreter (TCling.cxx:630)
==10148==    by 0x4FC7BDB: TROOT::InitInterpreter() (TROOT.cxx:2106)
==10148==    by 0x4FC81AE: ROOT::Internal::GetROOT2() (TROOT.cxx:388)
==10148==    by 0x108BAD: main (LsRoot.C:35)
==10148== 
==10148== 128 bytes in 1 blocks are possibly lost in loss record 2,152 of 3,056
==10148==    at 0x4C3017F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10148==    by 0xA4EDDBC: llvm::User::operator new(unsigned long) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x852646C: clang::CodeGen::CodeGenModule::GetOrCreateLLVMFunction(llvm::StringRef, llvm::Type*, clang::GlobalDecl, bool, bool, bool, llvm::AttributeList, clang::CodeGen::ForDefinition_t) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x85ECC7A: clang::CodeGen::CodeGenModule::getAddrOfCXXStructor(clang::CXXMethodDecl const*, clang::CodeGen::StructorType, clang::CodeGen::CGFunctionInfo const*, llvm::FunctionType*, bool, clang::CodeGen::ForDefinition_t) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x85961FA: (anonymous namespace)::ItaniumCXXABI::EmitDestructorCall(clang::CodeGen::CodeGenFunction&, clang::CXXDestructorDecl const*, clang::CXXDtorType, bool, bool, clang::CodeGen::Address) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x8609274: clang::CodeGen::CodeGenFunction::destroyCXXObject(clang::CodeGen::CodeGenFunction&, clang::CodeGen::Address, clang::QualType) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x8629D84: clang::CodeGen::CodeGenFunction::emitDestroy(clang::CodeGen::Address, clang::QualType, void (*)(clang::CodeGen::CodeGenFunction&, clang::CodeGen::Address, clang::QualType), bool) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x8617673: EmitCleanup(clang::CodeGen::CodeGenFunction&, clang::CodeGen::EHScopeStack::Cleanup*, clang::CodeGen::EHScopeStack::Cleanup::Flags, clang::CodeGen::Address) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x861A401: clang::CodeGen::CodeGenFunction::PopCleanupBlock(bool) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x861C2F6: clang::CodeGen::CodeGenFunction::PopCleanupBlocks(clang::CodeGen::EHScopeStack::stable_iterator, std::initializer_list<llvm::Value**>) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x861C743: clang::CodeGen::CodeGenFunction::PopCleanupBlocks(clang::CodeGen::EHScopeStack::stable_iterator, unsigned long, std::initializer_list<llvm::Value**>) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x8663166: (anonymous namespace)::AggExprEmitter::Visit(clang::Expr*) (in /opt/root/20180731/lib/libCling.so)
==10148== 
==10148== 128 bytes in 1 blocks are possibly lost in loss record 2,154 of 3,056
==10148==    at 0x4C3017F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10148==    by 0xA4EDDBC: llvm::User::operator new(unsigned long) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0xA4CF00B: llvm::Module::getOrInsertFunction(llvm::StringRef, llvm::FunctionType*) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0xA4773F3: llvm::Intrinsic::getDeclaration(llvm::Module*, llvm::Intrinsic::ID, llvm::ArrayRef<llvm::Type*>) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x90E3E5B: llvm::StackProtector::RequiresStackProtector() (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x90E7127: llvm::StackProtector::runOnFunction(llvm::Function&) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0xA4B3820: llvm::FPPassManager::runOnFunction(llvm::Function&) [clone .part.406] (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0xA4B38F9: llvm::FPPassManager::runOnModule(llvm::Module&) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0xA4B2A09: llvm::legacy::PassManagerImpl::run(llvm::Module&) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x841BB3A: std::_Function_handler<llvm::Expected<unsigned long> (), llvm::orc::LazyEmittingLayer<llvm::orc::IRCompileLayer<cling::IncrementalJIT::RemovableObjectLinkingLayer, llvm::orc::SimpleCompiler> >::EmissionDeferredModule::find(llvm::StringRef, bool, llvm::orc::IRCompileLayer<cling::IncrementalJIT::RemovableObjectLinkingLayer, llvm::orc::SimpleCompiler>&)::{lambda()#1}>::_M_invoke(std::_Any_data const&) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x8410DB6: cling::IncrementalExecutor::getPointerToGlobalFromJIT(llvm::GlobalValue const&) (in /opt/root/20180731/lib/libCling.so)
==10148==    by 0x83ADF9E: cling::Interpreter::Interpreter(int, char const* const*, char const*, bool, cling::Interpreter const*) (in /opt/root/20180731/lib/libCling.so)
==10148== 
==10148== LEAK SUMMARY:
==10148==    definitely lost: 0 bytes in 0 blocks
==10148==    indirectly lost: 0 bytes in 0 blocks
==10148==      possibly lost: 288 bytes in 3 blocks
==10148==    still reachable: 24,955,117 bytes in 35,410 blocks
==10148==                       of which reachable via heuristic:
==10148==                         multipleinheritance: 928 bytes in 2 blocks
==10148==         suppressed: 16,704 bytes in 184 blocks
==10148== Reachable blocks (those to which a pointer was found) are not shown.
==10148== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==10148== 
==10148== For counts of detected and suppressed errors, rerun with: -v
==10148== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 180 from 66)

Either I am doing something wrong with gROOT or the suppression file maybe need to be completed. Can someone help me with that ?

Cheers,
Marco

Thanks for reporting! I will have a look, please ping me if you don’t hear back by the end of this week!
Axel.

Ping ! :slight_smile:

Hi Marco,

I had a look, finally - apologies this took me so long. I get no error in master:

valgrind --num-callers=50 --track-origins=yes --suppressions=$ROOTSYS/etc/valgrind-root.supp  ./a.out
==30224== Memcheck, a memory error detector
==30224== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==30224== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==30224== Command: ./a.out
==30224==
0x5620d80
==30224==
==30224== HEAP SUMMARY:
==30224==     in use at exit: 28,821,665 bytes in 37,774 blocks
==30224==   total heap usage: 86,174 allocs, 48,400 frees, 55,792,341 bytes allocated
==30224==
==30224== LEAK SUMMARY:
==30224==    definitely lost: 0 bytes in 0 blocks
==30224==    indirectly lost: 0 bytes in 0 blocks
==30224==      possibly lost: 0 bytes in 0 blocks
==30224==    still reachable: 28,802,497 bytes in 37,556 blocks
==30224==                       of which reachable via heuristic:
==30224==                         multipleinheritance: 928 bytes in 2 blocks
==30224==         suppressed: 19,168 bytes in 218 blocks
==30224== Rerun with --leak-check=full to see details of leaked memory
==30224==
==30224== For counts of detected and suppressed errors, rerun with: -v
==30224== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 152 from 4)

Which OS, which compiler, where did you get ROOT from?

Cheers, Axel.

I am using GCC7 with Ubuntu 18.04.
I compiled root myself, without specific option except the FFTW included

Since last time I updated ROOT to the last pre-compiled version as I do not really need fftw anymore.

I can give it a try with my last config later today if you want

Sorry - I saw only know that valgrind reports them as “possibly lost”. AFAIK it really means this: it cannot tell for sure. What we focus on is memory errors (use after free etc) and definitely lost - and those are all good, for both of us. I.e. there is no problem here that I am aware of.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.