Potential memory leak in clang triggered by findScope

[pcanal]

Check duplicate issues.

• Checked for duplicates

Description

As reported in https://root-forum.cern.ch/t/mem-leak-even-with-suppression-file/60330, we just simple executable:
CreateTreeTestv2.tar.gz, we get definitively lost report by valgrind:

==44592==    at 0x483A809: malloc (vg_replace_malloc.c:309)
==44592==    by 0x898CD15: clang::Parser::AnnotateTemplateIdToken(clang::OpaquePtr<clang::TemplateName>, clang::TemplateNameKind, clang::CXXScopeSpec&, clang::SourceLocation, clang::UnqualifiedId&, bool, bool) (in /export/home/jb242989/root_v6.32.02/lib/libCling.so.6.32.02)
==44592==    by 0x8921B63: clang::Parser::ParseOptionalCXXScopeSpecifier(clang::CXXScopeSpec&, clang::OpaquePtr<clang::QualType>, bool, bool, bool*, bool, clang::IdentifierInfo**, bool, bool) (in /export/home/jb242989/root_v6.32.02/lib/libCling.so.6.32.02)
==44592==    by 0x899A53C: clang::Parser::TryAnnotateCXXScopeToken(bool) (in /export/home/jb242989/root_v6.32.02/lib/libCling.so.6.32.02)
==44592==    by 0x80E5246: cling::LookupHelper::findScope(llvm::StringRef, cling::LookupHelper::DiagSetting, clang::Type const**, bool) const (in /export/home/jb242989/root_v6.32.02/lib/libCling.so.6.32.02)
==44592==    by 0x801074B: TCling::GetClassSharedLibs(char const*) (in /export/home/jb242989/root_v6.32.02/lib/libCling.so.6.32.02)
==44592==    by 0x801507A: TClingLookupHelper__ExistingTypeCheck(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (in /export/home/jb242989/root_v6.32.02/lib/libCling.so.6.32.02)
==44592==    by 0x4AB8C52: TClassEdit::TSplitType::ShortType(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, int) (in /export/home/jb242989/root_v6.32.02/lib/libCore.so.6.32.02)
==44592==    by 0x4AB98C0: TClassEdit::GetNormalizedName(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::basic_string_view<char, ...

Are those a real leak (they accumulate and could have been deleted), hoarding (they accumulate, are in use and can not be delete until the end) or one time (they are just not cleaned-up at the end?)

Reproducer

CreateTreeTestv2.tar.gz

make
valgrind --suppression=$ROOTSYS/etc/valgrind-root.supp createTree

ROOT version

Moving from 6.26/06 to 6.28/04 we’ve still a very large increase of mem leaks and it is still present in v6.32.02

Installation method

unknown

Operating system

Linux

Additional context

#13130

[pcanal]

In a similar issue: #14199, the problem was avoided by reducing the number of (indirect) calls to findScope (with the side-effect of reducing overall work needed).

[ferdymercury]

A smaller reproducer here. It seems the problem is triggered by TTree::Write

#include "TMemFile.h"
#include "TTree.h"

int main(int argc, char** argv)
{
    TMemFile *f = new TMemFile("f.root","RECREATE");
    TTree *t = new TTree("t","t");
    t->Write(); // If I comment this line, leak disappears
    f->Close();
    delete f;
}

[ferdymercury]

And a oneliner reproducer here:

valgrind --leak-check=full --suppressions=$ROOTSYS/etc/valgrind-root.supp root.exe -n -l -b -q -e 'TMemFile f("f.root", "RECREATE"); TTree t; t.Write(); f.Close()'

[devajithvs]

A smaller reproducer here. It seems the problem is triggered by TTree::Write

#include "TMemFile.h"
#include "TTree.h"

int main(int argc, char** argv)
{
    TMemFile *f = new TMemFile("f.root","RECREATE");
    TTree *t = new TTree("t","t");
    t->Write(); // If I comment this line, leak disappears
    f->Close();
    delete f;
}

I ran the above code in a for loop to see if the leak is recurring. I increased the iteration count by a significant factor, but the leak remained constant and did not increase with the iteration count. So maybe we just need to add this to the suppression file?

[hahnjo]

I think I agree with Valgrind's complaint here, I propose a fix in #16150.