TFractionFitter destructor tries to delete already deleted objects

ROOT
1

I have a TFractionFitter, where I want to swap out the data and MC histograms, because it is slightly faster than always creating a new fitter object (and this slightly faster is significant because I need to perform a few thousand toy fits).

When I do this in Python, at the end of the script (this only happens when exiting the interpreter afterwards), there seems to be some double deletion of objects.

Here is an example script showing the problem:

import ROOT

# set some example data up
sig = ROOT.TH1D("sig", "sig", 100, 0, 10)
sig.FillRandom('gaus')
bg = ROOT.TH1D("bg", "bg", 100, 0, 10)
bg.FillRandom('pol0')
data = ROOT.TH1D("data", "data", 100, 0, 10)
data.FillRandom(sig, 500)
data.FillRandom(bg, 1000)

# create fitter
templates = ROOT.TObjArray()
templates.Add(sig)
templates.Add(bg)
f = ROOT.TFractionFitter(data, templates)
# use it
f.Fit()

# replace data and MC histos
f.SetData(data)
for i in range(len(templates)):
    f.SetMC(i, templates[i])
# use it again
f.Fit()

# exit

And this is the resulting segmentation violation upon quitting Python:

===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
#0  0x00007ffb79d054aa in __GI___waitpid (pid=8917, stat_loc=stat_loc
entry=0x7fff4ca1c040, options=options
entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:29
#1  0x00007ffb79c7e2cb in do_system (line=<optimized out>) at ../sysdeps/posix/system.c:148
#2  0x00007ffb77b21768 in TUnixSystem::Exec (shellcmd=<optimized out>, this=0x561bff571450) at /cern/root-git2/core/unix/src/TUnixSystem.cxx:2119
#3  TUnixSystem::StackTrace (this=0x561bff571450) at /cern/root-git2/core/unix/src/TUnixSystem.cxx:2413
#4  0x00007ffb77b23dcc in TUnixSystem::DispatchSignals (this=0x561bff571450, sig=kSigSegmentationViolation) at /cern/root-git2/core/unix/src/TUnixSystem.cxx:3633
#5  <signal handler called>
#6  0x0000561c00fea460 in ?? ()
#7  0x00007ffb6989dbec in TFractionFitter::~TFractionFitter (this=0x561c00f90370, __in_chrg=<optimized out>) at /cern/root-git2/hist/hist/src/TFractionFitter.cxx:258
#8  0x00007ffb6989dc49 in TFractionFitter::~TFractionFitter (this=0x561c00f90370, __in_chrg=<optimized out>) at /cern/root-git2/hist/hist/src/TFractionFitter.cxx:260
#9  0x00007ffb77ad2eb1 in TClass::Destructor (this=0x561c00f88b70, obj=0x561c00f90370, dtorOnly=<optimized out>) at /cern/root-git2/core/meta/src/TClass.cxx:5074
#10 0x00007ffb78c57937 in PyROOT::op_dealloc_nofree (pyobj=pyobj
entry=0x7ffb6aaba3b0) at /cern/root-git2/bindings/pyroot/src/ObjectProxy.cxx:59
#11 0x00007ffb78c579a9 in PyROOT::(anonymous namespace)::op_dealloc (pyobj=0x7ffb6aaba3b0) at /cern/root-git2/bindings/pyroot/src/ObjectProxy.cxx:212
#12 0x0000561bfe0b3b7a in ?? ()
#13 0x0000561bfe0566db in PyDict_SetItem ()
#14 0x0000561bfe0b8dd3 in _PyModule_Clear ()
#15 0x0000561bfe0b88fa in PyImport_Cleanup ()
#16 0x0000561bfe0b6943 in Py_Finalize ()
#17 0x0000561bfe0537da in Py_Main ()
#18 0x00007ffb79c593f1 in __libc_start_main (main=0x561bfe053330 <main>, argc=2, argv=0x7fff4ca1ee78, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff4ca1ee68) at ../csu/libc-start.c:291
#19 0x0000561bfe05322a in _start ()
===========================================================


The lines below might hint at the cause of the crash.
You may get help by asking at the ROOT forum http://root.cern.ch/forum.
Only if you are really convinced it is a bug in ROOT then please submit a
report at http://root.cern.ch/bugs. Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#6  0x0000561c00fea460 in ?? ()
#7  0x00007ffb6989dbec in TFractionFitter::~TFractionFitter (this=0x561c00f90370, __in_chrg=<optimized out>) at /cern/root-git2/hist/hist/src/TFractionFitter.cxx:258
#8  0x00007ffb6989dc49 in TFractionFitter::~TFractionFitter (this=0x561c00f90370, __in_chrg=<optimized out>) at /cern/root-git2/hist/hist/src/TFractionFitter.cxx:260
#9  0x00007ffb77ad2eb1 in TClass::Destructor (this=0x561c00f88b70, obj=0x561c00f90370, dtorOnly=<optimized out>) at /cern/root-git2/core/meta/src/TClass.cxx:5074
#10 0x00007ffb78c57937 in PyROOT::op_dealloc_nofree (pyobj=pyobj
entry=0x7ffb6aaba3b0) at /cern/root-git2/bindings/pyroot/src/ObjectProxy.cxx:59
#11 0x00007ffb78c579a9 in PyROOT::(anonymous namespace)::op_dealloc (pyobj=0x7ffb6aaba3b0) at /cern/root-git2/bindings/pyroot/src/ObjectProxy.cxx:212
#12 0x0000561bfe0b3b7a in ?? ()
#13 0x0000561bfe0566db in PyDict_SetItem ()
#14 0x0000561bfe0b8dd3 in _PyModule_Clear ()
#15 0x0000561bfe0b88fa in PyImport_Cleanup ()
#16 0x0000561bfe0b6943 in Py_Finalize ()
#17 0x0000561bfe0537da in Py_Main ()
#18 0x00007ffb79c593f1 in __libc_start_main (main=0x561bfe053330 <main>, argc=2, argv=0x7fff4ca1ee78, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff4ca1ee68) at ../csu/libc-start.c:291
#19 0x0000561bfe05322a in _start ()
===========================================================
2

Hi,

I cannot reproduce this problem in C++. I suspect it is due to the Python-C++ interface.

Best

Lorenzo

3

Hi Lorenzo, yes it definitely is a problem of the interface and not directly of the underlying TFractionFitter (hence the pyROOT tag…).

4

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