Segmentation violation in "createHistogram"

Dear experts,
I am trying to build a RooAbsPdf in the following way:

  TF2 *funcTF2 = new TF2("funcTF2", polXY, xMin, xMax, zMin, zMax, nPar);
  hist->Fit("funcTF2","WLVR");
  RooAbsPdf* squareDalitz = RooFit::bindPdf(finalTF2, x,z) ;
  RooAbsPdf* finalPdf = new sqDalitzToMassesPdf("sqDalitzToMassesPdf","sqDalitzToMassesPdf", x, y, squareDalitz, &z);

where “sqDalitzToMassesPdf” is a class autogenerated by RooClassFactory whose evaluate is:

Double_t sqDalitzToMassesPdf::evaluate() const
 {
   // ENTER EXPRESSION IN TERMS OF VARIABLE ARGUMENTS HERE
   z->setVal( f(x, y) );
   return squareDalitz->getVal() ;
 }

My code works fine until I ask for the “createHistogram” method on “finalPdf” and it gives the attached stack trace.

The reason for this code structure is that I am only able to fit the (x,z) distribution with a TF2, but I need a RooAbsPdf as a function of the (x,y) variables.

Thank you,
Leonardo
Stack_trace.pdf (43.6 KB)

Hi,

Likely either z or squareDalitz is a null pointer. Maybe simply add printf("z=%p squareDalitz=%p, z, squareDalitz); as the first line of sqDalitzToMassesPdf::evaluate() to see which one? Then you’ll need to find out why it’s null.

I will ask Lorenzo for help, too - maybe it’s something obvious in RooFit’s variable handling that I don’t see.

Cheers, Axel.

Dear Axel,
neither “z” nor “squareDalitz” is null. The printf line you suggested to add gives:

z=0x7ffc2d6411b0
*** Break *** segmentation violation
squareDalitz=0x260fd90

and then the same stack trace.

Cheers,
Leo

Hi,

The we’ll need the debugger’s help. I suppose you run something like “root -l -q myScript.C”. Instead, please make sure you can compile your script, using root -l -b myScript.C+ (note tthe “+”). Once your script crashes as before (i.e. all compilation errors are fixed), please run

gdb --args root.exe -l -b myScript.C+

(yes, that “.exe” is intentional). The type “r” and the script will start and crash. Please send the output of

bt

Cheers, Axel.

I am already compiling my script with the “+”.
Please find attached the gdb output.

Thank you,
Leonardo
gdb_output.txt (2.89 KB)

Hi,

Okay great! Can you change “Analysis.C+” into “Analysis.C++g” (just for our debug session) and run again with gdb? Then once it crashes, send the output of “bt” from gdb.

Also, could you attach the actual code so O know what we are looking at?

Cheers, Axel.

Hi,
the new gdb output is attached.
The whole code is here:
github.com/lecriste/Z4430_AAFit … d01fde304d

and I run it with:
root -l run_Analysys.sh

Let me know if you need also the input root files.

Cheers,
Leo
gdb_bt_output.txt (13.4 KB)

Hi,

Argh, we need debug symbols for a different library: “sqDalitzToMassesPdf.cxx++g”. Sorry about that. Anyway, we have two options:

  • run with
valgrind --num-callers=30 --suppressions=$ROOTSYS/etc/valgrind-root.supp --suppressions=$ROOTSYS/etc/valgrind-root-python.supp' --track-origins=yes root.exe -l -b ...whatever-else-you-pass-to-root...

I suspect that cosKstar is invalid at the point of use. This, too, would benefit from “sqDalitzToMassesPdf.cxx++g”.

  • send the input files so I can debug this myself.

Cheers, Axel.

Hi,
thanks for the second option :slight_smile:
Here is the required input file:
dropbox.com/s/t0gdrn5x40fec … .root?dl=0

Cheers,
Leo

Hi Leonardo,

I did not find any run_Analysis.sh file to run your code. It would be nice if you can pack your code in a simple and minimal reproducer that we can ran easly.

One thing I notice in your snippet of code is, when binding a TF1 in a RooAbsPdf or RooAbsReal, you should make sure that the objects used to build the TF1 are still alive.

Cheers

Lorenzo

Hi Lorenzo,
I just pushed the run_Analysis.sh file, sorry for the oversgiht:
github.com/lecriste/Z4430_AAFit … nalysys.sh

The TF2 I am currently binding in a RooAbsPdf is this one:
github.com/lecriste/Z4430_AAFit … Fit.C#L127

and I think all of the arguments are still alive when I bind it here:
github.com/lecriste/Z4430_AAFit … Fit.C#L194

Thanks,
Leo

Hi,

I suspect the problem is caused from the fact that the TF2 you create cannot be correctly copied or clones.
I think createHistograms calls a clone of the pdf inside and this could cause the problem.

Can you maybe try by replacing createHIstogram with the asTF function ? You can always take the obtained as TF and make an histogram using the TF1::GetHistogram function ?

Best Regards

Lorenzo

Hi Lorenzo,
by replacing createHIstogram with the asTF and TF1::GetHistogram methods the code does not crash anymore.

However I noticed that the y variable I was using in the createHIstogram method was not contained in the RooAbsPdf as well. Once I make sure it is a RooAbsPdf variable, the createHIstogram method does not crash either. Perhaps createHIstogram needs some protection against such a request.

Thank you,
Leonardo

Dear all,
I managed to get the desired behaviour with this code:
github.com/lecriste/Z4430_AAFit … 5e1d33ff01

I have one last question:
according to the way RooFit returns the RooAbsPdf value, shall i add the Jacobian term in the evaluate method of the “derived” pdf or not?
github.com/lecriste/Z4430_AAFit … e317ab8R69

Thank you,
Leonardo