Valgrind reports leak when constructing TChain

[vepadulano]

Check duplicate issues.

• Checked for duplicates

Description

I see definitely lost: 8,904 bytes in 76 blocks with valgrind in a few different places, which apparently all boil down to the following series of calls

==174298==    at 0x484382F: malloc (vg_replace_malloc.c:431)
==174298==    by 0xB8A21C5: llvm::safe_malloc(unsigned long) (MemAlloc.h:26)
==174298==    by 0xB8A2ACC: clang::TemplateIdAnnotation::Create(clang::SourceLocation, clang::SourceLocation, clang::IdentifierInfo*, clang::OverloadedOperatorKind, clang::OpaquePtr<clang::TemplateName>, clang::TemplateNameKind, clang::SourceLocation, clang::SourceLocation, llvm::ArrayRef<clang::ParsedTemplateArgument>, bool, llvm::SmallVectorImpl<clang::TemplateIdAnnotation*>&) (ParsedTemplate.h:206)
==174298==    by 0xB90CA4B: clang::Parser::AnnotateTemplateIdToken(clang::OpaquePtr<clang::TemplateName>, clang::TemplateNameKind, clang::CXXScopeSpec&, clang::SourceLocation, clang::UnqualifiedId&, bool, bool) (ParseTemplate.cpp:1356)
==174298==    by 0xB893CA9: clang::Parser::ParseOptionalCXXScopeSpecifier(clang::CXXScopeSpec&, clang::OpaquePtr<clang::QualType>, bool, bool, bool*, bool, clang::IdentifierInfo**, bool, bool) (ParseExprCXX.cpp:506)
==174298==    by 0xB91DDED: clang::Parser::TryAnnotateCXXScopeToken(bool) (Parser.cpp:2094)
==174298==    by 0xA8FB2A9: cling::LookupHelper::findScope(llvm::StringRef, cling::LookupHelper::DiagSetting, clang::Type const**, bool) const (LookupHelper.cpp:629)
==174298==    by 0xA7FF96C: TClingClassInfo::TClingClassInfo(cling::Interpreter*, char const*, bool) (TClingClassInfo.cxx:87)

Full report from valgrind
valgrind_report.txt

Reproducer

ROOT was built with the following configuration

cmake -GNinja -DCMAKE_BUILD_TYPE=Debug -DLLVM_BUILD_TYPE=Debug

This is the reproducer

#include <TChain.h>
int main(){
    TChain c;
}

Compile and run with valgrind

$: g++ -g -o repro.out repro.cpp `root-config --cflags --glibs`
$: valgrind --leak-check=full --num-callers=30 --suppressions=$ROOTSYS/etc/valgrind-root.supp ./repro.out

ROOT version

master@1be2785

Installation method

built from source

Operating system

Fedora 37

Additional context

Compiler: GCC 12

I have arrived to the minimal reproducer above starting from the code in RSample.cxx which creates a temporary TChain in the constructor.

[eguiraud]

This is likely something to be added to the suppression file: jitting allocates and never deallocates.

[vgvassilev]

Indeed, @pcanal invested a lot of time to avoid these cases but we still have to allocate some memory on making lookups.

[Axel-Naumann]

This isn't jitting, and clang should not leak this. Please leave it open for me to look at in a couple of weeks. Thanks for the report!

[ferdymercury]

I get 0 bytes lost on Ubuntu 22.04 and 3b06c87 (valgrind 3.18)

[AxelKrypton]

Just for the records, working with a software that uses ROOT as a library and switching on the address sanitiser in our unit tests, we get the following report with all 6.28.XX versions:

==15==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8792 byte(s) in 75 object(s) allocated from:
    #0 0x7ff05e914887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x7ff04609ad21 in clang::Parser::AnnotateTemplateIdToken(clang::OpaquePtr<clang::TemplateName>, clang::TemplateNameKind, clang::CXXScopeSpec&, clang::SourceLocation, clang::UnqualifiedId&, bool, bool) (/SMASH/root_install/lib/libCling.so+0x15b5d21)

SUMMARY: AddressSanitizer: 8792 byte(s) leaked in 75 allocation(s).

Using ROOT 6.26.10 does not display the problem.

I am not sure this is exactly the same problem of this issue, but I did not want to open a new issue at first as in the description clang::Parser::AnnotateTemplateIdToken is part of the Valgrind output. If you need more information from my side, feel free to ask.

[Axel-Naumann]

Thanks - could you

• open a dedicated issue for this
• share way way more of the backtrace: ideally everything but at least until the first frame in TCling.

Thanks for investing your time here!

[dpiparo]

@vepadulano , not clear from the conversation to me, but is the comment above about the suppression file and how cling allocates addressing your original issue? If yes,could you close this item?

[ferdymercury]

This seems another occurrence: https://root-forum.cern.ch/t/memory-leak-during-repeated-fitting/58299/16 that also gets solved when going into 6.30. So maybe a backport for 6.28 would be useful.