PyRoot and RooFit - problems plotting on a frame


I am trying to write a simple macro to perform a fit in PyRoot+RooFit.
But I got a trouble. This is my code:

import ROOT


c1 = ROOT.TCanvas()
var = "zllmass"
h = ROOT.TFile.Open(“NoNorm_Mu/ZZEdmNtp.root”).Get(var)
x = ROOT.RooRealVar(“x”,“x”,0,10)
hist = ROOT.RooDataHist(var, “”, ROOT.RooArgList(x), h)
mean = ROOT.RooRealVar(“mean”,“mean of gaussians”,5,0,10)
sigma = ROOT.RooRealVar(“sigma”,“width of gaussians”,0.5)
gauss= ROOT.RooGaussian(“gauss”,“gaussian PDF”,x,mean,sigma) ;
xframe = x.frame()
print "before drawing"
print "after drawing"

I can run the macro completely, but as soon as it has finished it gives a Segmenation Violation.
It doesn’t happen if I comment gauss.plotOn(xframe).
Please, can you help me to understand what is beyond this behavior and how can I fix it?
Many thanks!



which release? There have been various problems with plotOn() due to the missing of “using” information in the dictionary. Another common problem with roofit is that it likes to cast const away from temporary objects.

Here, however, my main worry is this:ROOT.SetOwnership(xframe,True) as the RooPlot (the ‘frame’) already gets added to gDirectory, which is then responsible for cleanup. By telling python that it should clean up the frame as well, there are two attempts to delete the RooPlot on shutdown.


Hi Wim,

Thanks for the answer and sorry for my late reply. What it is not very clear to me in general, is how to define correctly the ownership of the objects. I mean there is a way to tell Python and Roofit who has to do what in a clear way avoiding to leave both of them the responsibility to clean up?

Many thanks,


P.S: Release–> ROOT 5.27/06b (branches/v5-27-06-patches@36515


there’s no way to tell, other than reading the documentation (of course, the same is true when working in C++: there simply is nothing in C++ pointer semantics that relays ownership). However, because of its heritage of being accessible from an interpreter (CINT), ROOT is pretty consistent in what needs to be cleaned up where, as well as that it has a communication mechanism for objects going dodo-bird. For those reasons, PyROOT can use heuristics (unless the memory policy is set to “strict”) that work quite decently in practice.