Seg fault on `.q` but not when deconstructing TObject

ROOT
1

Hi all, interesting one here… (imo)

So I have a homemade class lets call is a PlotClass.

When I for example in root terminal I do this:

root [0] Plot plot;
root [1] plot.AddData(data1);
root [2] plot.AddData(data2)
root [3] plot.LoadData()
root [4] .q

I get this big seg fault on the deconstructor of an object in the Plot class:

===========================================================
#6  0x00007fbfc4c80f78 in vtable for TString () from /home/lgolino/packages/root/install/lib/libCore.so
#7  0x00007fbfa81b71d2 in AnaReport::~AnaReport (this=0x5618bcb70000, __in_chrg=<optimized out>) at /home/lgolino/alphasofts/A2Run_2023/analib/src/AnaReport.cxx:80
#8  0x00007fbfa6149b1f in std::_Destroy<AnaReport> (__pointer=0x5618bcb70000) at /usr/include/c++/9/bits/stl_construct.h:98
#9  0x00007fbfa6148c51 in std::_Destroy_aux<false>::__destroy<AnaReport*> (__first=0x5618bcb70000, __last=0x5618bcb70430) at /usr/include/c++/9/bits/stl_construct.h:108
#10 0x00007fbfa614755c in std::_Destroy<AnaReport*> (__first=0x5618bcb70000, __last=0x5618bcb70430) at /usr/include/c++/9/bits/stl_construct.h:137
#11 0x00007fbfa6146041 in std::_Destroy<AnaReport*, AnaReport> (__first=0x5618bcb70000, __last=0x5618bcb70430) at /usr/include/c++/9/bits/stl_construct.h:206
#12 0x00007fbfa6145157 in std::vector<AnaReport, std::allocator<AnaReport> >::~vector (this=0x7fbfbe557738, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/stl_vector.h:677
#13 0x00007fbfa613c8cc in Plot::~Plot (this=0x7fbfbe557190, __in_chrg=<optimized out>) at /home/lgolino/alphasofts/A2Run_2023/rootUtils/src/TA2Plot.cxx:58
#14 0x00007fbfc00c4b8e in cling::IncrementalExecutor::runAndRemoveStaticDestructors(cling::Transaction*) () from /home/lgolino/packages/root/install/lib/libCling.so
#15 0x00007fbfc0039271 in cling::Interpreter::runAndRemoveStaticDestructors() () from /home/lgolino/packages/root/install/lib/libCling.so
#16 0x00007fbfbff2fa10 in TCling::ResetGlobals() () from /home/lgolino/packages/root/install/lib/libCling.so
#17 0x00007fbfc48eafb1 in TROOT::EndOfProcessCleanups() () from /home/lgolino/packages/root/install/lib/libCore.so
#18 0x00007fbfc4a49af3 in TUnixSystem::Exit(int, bool) () from /home/lgolino/packages/root/install/lib/libCore.so
#19 0x00007fbfc48f78af in TApplication::Terminate(int) () from /home/lgolino/packages/root/install/lib/libCore.so
===========================================================

However, calling the deconstructor on the same object does this:

root [0] Plot plot;
root [1] plot.AddData(data1);
root [2] plot.AddData(data2)
root [3] plot.LoadData()
root [4] plot.~Plot()
root [5] .q
double free or corruption (!prev)

but doesn’t get fault. Doing all of that in a macro:

root [0] .L PlotCrashTest.C
root [1] PlotCrashTest()
root [2] .q

Exits fine, I am constructing a Plot object in there, and doing the same stuff. So it is deconstructing after the macro (by default).

Anyone have any idea whats going on here?

Cheers

Please read tips for efficient and successful posting and posting code

Please fill also the fields below. Note that root -b -q will tell you this info, and starting from 6.28/06 upwards, you can call .forum bug from the ROOT prompt to pre-populate a topic.

_ROOT Version: 6.26/06
_Platform: ubuntu20.04
_Compiler:gcc

2

Hi,
The problem looks to be caused by the destructor of your class. Please check that it works as expected

Lorenzo

3

But does it make sense that calling the deconstructor implicitly, or the default at the end of scope works fine, but only in command line in root does it cause the seg fault?

4

This can happen if the destructor of your class can interfere with some of the ROOT classes that are automatically deleted when exiting ROOT. Also there could be some specific order required when deleting your class.

Lorenzo

5

It does not work fine. It just fails differently. Please try running your example with valgrind:

valgrind --suppressions=$ROOTSYS/etc/valgrind-root.supp root.exe -b -l
6

Fair point, thanks to @moneta I traced it down to two TH1I* that I was deleting in the deconstructor. Not sure why but removing those lines removed the issue.

7

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