Randomly a segmentation fault for uninitialized TTree

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.

I have no big success running valgrind:

% valgrind -s --tool=memcheck  ./mini 
valgrind: mmap-FIXED(0x7fff5f400000, 8388608) failed in UME (load_unixthread1) with error 22 (Invalid argument).
%

Ah, so we are two of us! :sweat_smile: :sob:

Yes, I know very well that stuff on closing the root application.
I am tempted to send you the real program, the one that makes a lot of plots, the one that randomly crashes after that every thing is done…
But I want to try on a lxplus before…

Evviva! On lxplus my big program (working on my mac quite apart from the random crashes) crashes regularly on filling some histograms and thus before plotting them on canvases! :rofl:
Ironically, maybe this could help!

At filling time ? may be you are filling them with NaN or Inf ?

I’m going to check: it’s funny, isn’t it? Why not the same problem on mac?
OK, It’s not the first time I have to fight with ROOT, grrr!

Right after “file_ = TFile::Open(...);” line, try to add:
gROOT->cd(); // newly created histograms should go here

Different behaviours on different machines is not specific to ROOT. It might be the case with any program. That’s why it is always recommended to run a program on different machines.

No, no: the problem is with a complex std::map of the type

< string, <string, TH1F * > >

I will use my craft methods to find the problem and the solution presented on lxplus, not on my mac
(crazy!)

Well, I found a tiny subtle bug in my code and now on the mac I am not having crashes any more!
On lxplus, instead, there I am having a sistematic crash (the same code)
I will solve this as well!

===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
    gdb.printing.register_pretty_printer(gdb.current_objfile(),
    gdb.printing.register_pretty_printer(gdb.current_objfile(),
#0  0x00007faf2bb6446c in waitpid () from /lib64/libc.so.6
#1  0x00007faf2bae1f62 in do_system () from /lib64/libc.so.6
#2  0x00007faf304ff58c in TUnixSystem::StackTrace() () from /usr/lib64/root/libCore.so.6.22
#3  0x00007faf3050201a in TUnixSystem::DispatchSignals(ESignals) () from /usr/lib64/root/libCore.so.6.22
#4  <signal handler called>
#5  0x0000000000463862 in ROOT::Math::MinimizerOptions::SetMaxFunctionCalls(unsigned int) ()
#6  0x00000000004638ec in ROOT::Math::Minimizer::SetMaxFunctionCalls(unsigned int) ()
#7  0x0000000000462bb4 in FitHist2Hist::_fit(double*, double*, char const*, char const*, int) ()
#8  0x0000000000462ffa in FitHist2Hist::go(double) ()
#9  0x0000000000447e14 in Analisi::look_for_gamma(std::map<std::string, TH1F*, std::less<std::string>, std::allocator<std::pair<std::string const, TH1F*> > >&) ()
#10 0x000000000044687c in Analisi::fillHistograms(std::vector<std::string, std::allocator<std::string> >) ()
#11 0x000000000043857a in main ()
===========================================================

I will solve this as well.
Thank you!

On lxplus: gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
On the mac: MacOSX10.15.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.27)
The latter looks like a… liberal compiler! :laughing:

So, I solved all the instability problems of my code when running on my mac just solving a number of very subtle source of segmentation fault on lxplus. On mac now it works stably!
Not on lxplus for what follows.
I am using the code you find here
https://root.cern/doc/v610/NumericalMinimization_8C_source.html
This is a fragment:

   ROOT::Math::Minimizer* minimum =
       ROOT::Math::Factory::CreateMinimizer(minName, algoName);  
    // set tolerance , etc...
    minimum->SetMaxFunctionCalls(1000000); // for Minuit/Minuit2
    minimum->SetMaxIterations(10000);  // for GSL
    minimum->SetTolerance(0.001);
    minimum->SetPrintLevel(1);

On my mac it works fine; on lxplus it generates a segmentation fault at the SetMaxFunctionCalls
Indeed ROOT::Math::Factory::CreateMinimizer(minName, algoName) returns zero!!!
Any idea?

Ah! I have just found everything is OK on lxplus too, if I do not specify any minimizer, i.e. minuit or minuit2 etc.) and assume the default (which I am not able to find which indeed it is: great documentation, I will say!)
But again: why on my mac specifying “Minuit2” does work?