Randomly a segmentation fault for uninitialized TTree

ok, I will do!

Again, bytes lost don’t cause crashes :sweat: They possibly cause higher memory usage, but that’s a different issue.

Does ROOT print a stacktrace at the point of crash?
Can you provide a reproducer for the crash?

OK, without the leack-check I get
==81987==
==81987== HEAP SUMMARY:
==81987== in use at exit: 46,910,455 bytes in 67,571 blocks
==81987== total heap usage: 341,957 allocs, 274,386 frees, 185,029,169 bytes allocated
==81987==
==81987== LEAK SUMMARY:
==81987== definitely lost: 13,008 bytes in 80 blocks
==81987== indirectly lost: 32 bytes in 1 blocks
==81987== possibly lost: 7,656 bytes in 161 blocks
==81987== still reachable: 44,989,590 bytes in 59,467 blocks
==81987== of which reachable via heuristic:
==81987== newarray : 23,896 bytes in 41 blocks
==81987== suppressed: 1,900,169 bytes in 7,862 blocks
==81987== Rerun with --leak-check=full to see details of leaked memory
==81987==
==81987== For lists of detected and suppressed errors, rerun with: -s
==81987== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3118 from 14)

That looks fine, 13kB of memory lost is most probably due to the ROOT interpreter just-in-time compiling something, and it should be harmless/expected.

OK, I am getting back onto the big program :mask:

Try with the AddressSanitizer, e.g.:

`root-config --cxx --cflags` -O0 -g -fno-omit-frame-pointer -fsanitize=address -Wall -Wextra -o a.out *.cpp -lasan `root-config --libs`
ASAN_OPTIONS="verbosity=1:abort_on_error=0" ./a.out

For today with the big program: version 6.22 of root, not using AddressSanitized (that I have to understand yet), compilation fine with
CXXFLAGS = -g -O3 -Wall -Wextra -fPIC -ftemplate-depth-30

Everything fine in running for three times; at the fourth time segmentation fault after all the histograms were plotted in their canvases.
I attach the messages given at the event:
segfault.txt (4.1 KB)

Line 135 of makeAnalysis.cpp is the very very and line of the main() (namely, containing the closing “}”

The very last lines in the main() are
app.Run(kTRUE); // kTRUE let the program continue after quitting ROOT
delete esempi;
delete analisi;
return 0 ;

Deleting object “analisi” means deleting all the histograms that were constructed and with which plots are done: I have never understood the timing of the quitting of the root session. It could randomly happen that root terminates the quitting process later then the “analisi” object is deleted… thus the segmentation fault! May it be?

Try (you should then see where it dies):

app.Run(kTRUE); // kTRUE = the main application eventloop returns here
gSystem->ProcessEvents(); gSystem->ProcessEvents(); // MacOS fix
std::cout << "first sleep" << std::endl; sleep(1);
// gSystem->ProcessEvents(); gSystem->ProcessEvents(); // MacOS fix
delete esempi;
gSystem->ProcessEvents(); gSystem->ProcessEvents(); // MacOS fix
std::cout << "second sleep" << std::endl; sleep(1);
// gSystem->ProcessEvents(); gSystem->ProcessEvents(); // MacOS fix
delete analisi;
gSystem->ProcessEvents(); gSystem->ProcessEvents(); // MacOS fix
std::cout << "third sleep" << std::endl; sleep(1);
// gSystem->ProcessEvents(); gSystem->ProcessEvents(); // MacOS fix
return 0;

In the meanwhile I run the big program with valgrind.

lazi@light allFiles % valgrind --tool=memcheck --suppressions=root-config --etcdir/valgrind-root.supp ./makeAnalysis 2&> Valgrind.output

Analysis set from June 01, 2020
Data as at February 02, 2021

zsh: segmentation fault valgrind --tool=memcheck ./makeAnalysis 2&> Valgrind.output
lazi@light allFiles %Valgrind.txt (8.5 KB)

816] Booking histograms done!
makeAnalysis(14368,0x10f215dc0) malloc: Region cookie corrupted for region 0x7f816b800000 (value is 4695a000)[0x7f816b8081fc]
makeAnalysis(14368,0x10f215dc0) malloc: *** set a breakpoint in malloc_error_break to debug
zsh: abort      ./makeAnalysis

This is something I don’t know how to do!

I see the crash is in TGCocoa::DestroyWindow . Hard to tells what’s wrong just with this traceback. We would need some reproducer to go further.

I do not know what you mean for “reproducer”. Anyway I noticed something connected to creating the TApplication object. So I made a minimal program that looks like a “reproducer”.
Running with valgrind I have

lazi@light PROVA % valgrind -s --tool=memcheck  --suppressions=`root-config --etcdir`/valgrind-root.supp ./makeMini 2&> Valgrind.txt
TApplication setting
zsh: segmentation fault  valgrind -s --tool=memcheck  ./makeMini 2&> Valgrind.txt

I enclose a tar of the full staff, including the valgrind report.
Notice: I am using root 6.22/06 The ROOT Team; conception: R. Brun, F. Rademakers
Built for macosx64 on Nov 27 2020, 15:14:08 |
From tags/v6-22-06@v6-22-06
last_incredible.tgz (47.2 KB)

when I run you program I get:

% ./mini
TApplication setting
TApplication set!
./makeTree.root doesn't exist... exiting

makeTree.root (211.4 KB)

Yes, of course i forgot to include the data root file.

So it runs now. I get a TTree Print() and then:

[...]
Analysis set from June 01, 2020
Data as at February 02, 2021

And that’s all … nothing else, no crash … the program does not stop by itself. Control-C is needed to stop it.

If I use just

{  
  Analisi * analisi = new Analisi("./makeTree.root") ;  
  delete analisi;
  return 0 ;
}

that is what happens to me as well, of course. Instead using

{
  cout << "TApplication setting" << endl;
  TApplication app("analisi",&argc,argv);
  cout << "TApplication set!" << endl;
  Analisi * analisi = new Analisi("./makeTree.root") ;
  app.Run(kTRUE);  
  delete analisi;
  return 0 ;
}

I have the absurd problem.
May you find any anomaly in my Makefile?

Instead of:

TApplication app(...);
// ...
app.Run(kTRUE);

try:

TApplication *app = new TApplication(...);
// ...
app->Run(kTRUE);

Another thing worth of trying would be to set “X11.UseXft: no” in the “${ROOTSYS}/etc/system.rootrc” file (or in your own “${HOME}/.rootrc” file).

BTW. In your “makeMini.cpp”, you need to draw some canvas in order to be able to “File -> Quit ROOT” so, simply add (before “Run”, of course): new TCanvas("c", "c");

Ah, I forgot to specify that the trouble is when running the program with valgrind; otherwise it works fine! But I need valgrind to try to find out why the big program crashes randomly.
I hope you have understood the point.