Memory leaks with Clone()

[rlalik]

Check duplicate issues.

• Checked for duplicates

Description

I have simple code cloning TF1 object with Clone() (MWE below) compiled following way:

g++ example3.cpp -fsanitize=address,undefined -o example3 -isystem /usr/include/root /usr/lib64/root/libHist.so.6.34.02 /usr/lib64/root/libCore.so.6.34.02

When compiling with Clone() I have several memory leaks:

=================================================================
==29703==ERROR: LeakSanitizer: detected memory leaks

Indirect leak of 736 byte(s) in 10 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f87b873c in TStorage::ObjectAlloc(unsigned long) (/usr/lib64/root/libCore.so.6.34+0x20b73c)

Indirect leak of 512 byte(s) in 8 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f749454a in std::vector<TStreamerInfoActions::TConfiguredAction, std::allocator<TStreamerInfoActions::TConfiguredAction> >::reserve(unsigned long) (/usr/lib64/root/libRIO.so.6.34+0x23a54a)

Indirect leak of 328 byte(s) in 1 object(s) allocated from:
    #0 0x7f79f8fdfc18 in operator new[](unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfbc18)
    #1 0x7f79f7429717 in TStreamerInfo::Compile() (/usr/lib64/root/libRIO.so.6.34+0x1cf717)

Indirect leak of 192 byte(s) in 1 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f87b873c in TStorage::ObjectAlloc(unsigned long) (/usr/lib64/root/libCore.so.6.34+0x20b73c)
    #2 0x7f79f73e160a in TStreamerInfo::GenerateInfoForPair(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> > const&, bool, unsigned long, unsigned long) (/usr/lib64/root/libRIO.so.6.34+0x18760a)

Indirect leak of 184 byte(s) in 1 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f87b873c in TStorage::ObjectAlloc(unsigned long) (/usr/lib64/root/libCore.so.6.34+0x20b73c)
    #2 0x7f79f73e1584 in TStreamerInfo::GenerateInfoForPair(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> > const&, bool, unsigned long, unsigned long) (/usr/lib64/root/libRIO.so.6.34+0x187584)

Indirect leak of 128 byte(s) in 1 object(s) allocated from:
    #0 0x7f79f8fdfc18 in operator new[](unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfbc18)
    #1 0x7f79f881da8b in TObjArray::Init(int, int) (/usr/lib64/root/libCore.so.6.34+0x270a8b)

Indirect leak of 80 byte(s) in 2 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f74203e4 in TStreamerInfo::AddWriteAction(TStreamerInfoActions::TActionSequence*, int, TStreamerInfo::TCompInfo*) (/usr/lib64/root/libRIO.so.6.34+0x1c63e4)

Indirect leak of 80 byte(s) in 2 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f74254c1 in TStreamerInfo::AddWriteMemberWiseVecPtrAction(TStreamerInfoActions::TActionSequence*, int, TStreamerInfo::TCompInfo*) (/usr/lib64/root/libRIO.so.6.34+0x1cb4c1)

Indirect leak of 80 byte(s) in 2 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f74200f4 in TStreamerInfo::AddWriteAction(TStreamerInfoActions::TActionSequence*, int, TStreamerInfo::TCompInfo*) (/usr/lib64/root/libRIO.so.6.34+0x1c60f4)

Indirect leak of 80 byte(s) in 2 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f74205c9 in TStreamerInfo::AddReadTextAction(TStreamerInfoActions::TActionSequence*, int, TStreamerInfo::TCompInfo*) (/usr/lib64/root/libRIO.so.6.34+0x1c65c9)

Indirect leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f7411127  (/usr/lib64/root/libRIO.so.6.34+0x1b7127)

Indirect leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f742130f in TStreamerInfo::AddReadAction(TStreamerInfoActions::TActionSequence*, int, TStreamerInfo::TCompInfo*) (/usr/lib64/root/libRIO.so.6.34+0x1c730f)
    #2 0x7f79f74295d8 in TStreamerInfo::Compile() (/usr/lib64/root/libRIO.so.6.34+0x1cf5d8)

Indirect leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f741fb39 in TStreamerInfo::AddWriteTextAction(TStreamerInfoActions::TActionSequence*, int, TStreamerInfo::TCompInfo*) (/usr/lib64/root/libRIO.so.6.34+0x1c5b39)

Indirect leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f741fe4b in TStreamerInfo::AddWriteTextAction(TStreamerInfoActions::TActionSequence*, int, TStreamerInfo::TCompInfo*) (/usr/lib64/root/libRIO.so.6.34+0x1c5e4b)

Indirect leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f742130f in TStreamerInfo::AddReadAction(TStreamerInfoActions::TActionSequence*, int, TStreamerInfo::TCompInfo*) (/usr/lib64/root/libRIO.so.6.34+0x1c730f)
    #2 0x7f79f742956c in TStreamerInfo::Compile() (/usr/lib64/root/libRIO.so.6.34+0x1cf56c)

Indirect leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f741185c  (/usr/lib64/root/libRIO.so.6.34+0x1b785c)

Indirect leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f7421420 in TStreamerInfo::AddReadAction(TStreamerInfoActions::TActionSequence*, int, TStreamerInfo::TCompInfo*) (/usr/lib64/root/libRIO.so.6.34+0x1c7420)
    #2 0x7f79f74295d8 in TStreamerInfo::Compile() (/usr/lib64/root/libRIO.so.6.34+0x1cf5d8)

Indirect leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x7f79f8fdfa88 in operator new(unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfba88)
    #1 0x7f79f7421420 in TStreamerInfo::AddReadAction(TStreamerInfoActions::TActionSequence*, int, TStreamerInfo::TCompInfo*) (/usr/lib64/root/libRIO.so.6.34+0x1c7420)
    #2 0x7f79f742956c in TStreamerInfo::Compile() (/usr/lib64/root/libRIO.so.6.34+0x1cf56c)

Indirect leak of 32 byte(s) in 1 object(s) allocated from:
    #0 0x7f79f8fdfc18 in operator new[](unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfbc18)
    #1 0x7f79f87bb2e0 in TString::Clobber(int) (/usr/lib64/root/libCore.so.6.34+0x20e2e0)

Indirect leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x7f79f8fdfc18 in operator new[](unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfbc18)
    #1 0x7f79f7429236 in TStreamerInfo::Compile() (/usr/lib64/root/libRIO.so.6.34+0x1cf236)

Indirect leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x7f79f8fdfc18 in operator new[](unsigned long) (/usr/lib/gcc/x86_64-pc-linux-gnu/14/libasan.so.8+0xfbc18)
    #1 0x7f79f742922a in TStreamerInfo::Compile() (/usr/lib64/root/libRIO.so.6.34+0x1cf22a)

SUMMARY: AddressSanitizer: 2784 byte(s) leaked in 41 allocation(s).

whereas the IsA()->New() code (which I took from void HFit::StoreAndDrawFitFunction() seems safe.

So, any odea why Clone() results with leaks? Should it be fixed? Should Clone() be not used?

Reproducer

MWE:

#include <TClass.h>
#include <TF1.h>

auto main() -> int
{
    auto f1 = std::make_unique<TF1>("f1", "gaus", -10, 10);
    f1->Print();

    // This has leaks
    auto aaa = f1->Clone();
    aaa->Print();
    delete aaa;

    // This has no leaks
    auto bbb = (TF1*)(f1->IsA()->New());
    f1->Copy(*bbb);
    bbb->Print();
    delete bbb;

    return 0;
}

ROOT version

Many version, cuurently 6.34.02

Installation method

Build from source (Gentoo)

Operating system

Linux

Additional context

No response

[ferdymercury]

This is maybe related with ROOT's suppression file. If I run with valgrind, I get:

valgrind --tool=memcheck --suppressions=$ROOTSYS/etc/valgrind-root.supp --leak-check=full root.exe /tmp/test.cpp+ -b -q
==213476== Memcheck, a memory error detector
==213476== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==213476== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==213476== Command: root.exe /tmp/test.cpp+ -b -q
==213476== Parent PID: 213355
==213476== 
==213476== 
==213476== HEAP SUMMARY:
==213476==     in use at exit: 22,139,548 bytes in 32,263 blocks
==213476==   total heap usage: 589,881 allocs, 557,618 frees, 410,578,575 bytes allocated
==213476== 
==213476== LEAK SUMMARY:
==213476==    definitely lost: 0 bytes in 0 blocks
==213476==    indirectly lost: 0 bytes in 0 blocks
==213476==      possibly lost: 0 bytes in 0 blocks
==213476==    still reachable: 22,007,098 bytes in 30,630 blocks
==213476==                       of which reachable via heuristic:
==213476==                         newarray           : 8,016 bytes in 12 blocks
==213476==                         multipleinheritance: 3,552 bytes in 6 blocks
==213476==         suppressed: 132,450 bytes in 1,633 blocks
==213476== Reachable blocks (those to which a pointer was found) are not shown.
==213476== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==213476== 
==213476== For lists of detected and suppressed errors, rerun with: -s
==213476== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 899 from 104)

[rlalik]

Can you reproduce my problem when using sanitizers not valgrind?

[ferdymercury]

Nope, not really:

g++ mwe.cpp -fsanitize=address,undefined -o example3 -isystem /home/user/build/build-root-Desktop-Debug/include /home/user/build/build-root-Desktop-Debug/lib/libHist.so /home/user/build/build-root-Desktop-Debug/lib/libCore.so
and then running ./example3

Gives me:
sometimes just:

Formula based function:     f1 
                   f1 : gaus Ndim= 1, Npar= 3, Number= 100 
 Formula expression: 
	[Constant]*exp(-0.5*((x-[Mean])/[Sigma])*((x-[Mean])/[Sigma])) 
Formula based function:     f1 
                   f1 : gaus Ndim= 1, Npar= 3, Number= 100 
 Formula expression: 
	[Constant]*exp(-0.5*((x-[Mean])/[Sigma])*((x-[Mean])/[Sigma])) 
Formula based function:     f1 
                   f1 : gaus Ndim= 1, Npar= 3, Number= 100 
 Formula expression: 
	[Constant]*exp(-0.5*((x-[Mean])/[Sigma])*((x-[Mean])/[Sigma]))

and sometimes an infinite loop of AddressSanitizer:DEADLYSIGNAL

on Ubu22.04

[rlalik]

I have some more findings. First, since I had different root installations on my machine, I tried the same code with few of them and I found out that for some of them the sanitizer was OK. So I took gentoo-system-wide installation (which is not OK) and I was checking what is breaking it. And surprisingly, I found one cmake setting which fixes the issue.

Attached is the CMakeCache and some modified gentoo-toolchains files. This config gives NOT OK root build.
config.zip

If I change line 3080 of Cache file from tmva-pymva:BOOL=yes to tmva-pymva:BOOL=no, the sanitizer shows no memory leaks any more

How to use these files:

1. in your root sources directory create build_cmake/custom end cd there
2. unpack the archive directly into it
3. update the paths: sed -e "s|/home/rafal/projects/cern/root/build_cmake/custom|${PWD}|g" -i Makefile CMakeCache.txt
4. you perhaps will also like to update the CMAKE_INSTALL_PREFIX to fit your preferences.

Another program which demonstrates the issue:

#include <TFile.h>
#include <TF1.h>
#include <TH1.h>

auto main() -> int
{
    auto hist = std::make_unique<TH1I>("test_hist", "", 100, 0, 10);
    hist->SetBinContent(1, 7290);

    TF1 * f_fit = new TF1("f_fit", "gaus", 0, 10);

    hist.get()->Fit(f_fit); // either comment this

    TFile* fp = TFile::Open("root_outout_name.root", "RECREATE");
    if (fp) {
        hist->Write();      // or this to fix sanitizer
    }
    fp->Close();

    delete fp;

    return 0;
}

This program shows leaks, but commenting out/removing either line fit Fit()call orWrite()` call shows no more leaks.

[ferdymercury]

One question, could you run the leaking part within an "infinite loop", to see if the memory increases, or if it's just a one-time initialization / forgot-to-delete-at-close leak?