ROOT.TH1F.DrawNormalized() crashes with v5.32.01

Hello everyone,

In the PyRoot example “hsimple.py”, I added the following lines to the existing example:

ntuple.Draw("py") h = c1.GetPrimitive("htemp") h = h.DrawNormalized()

This works perfectly with Root v5.26.01, but with v5.32.01, I got a segmentation violation error:

[quote]---- *** Break *** segmentation violation

===========================================================
There was a crash (#8 0xb62a4e9d in SigHandler () from /home/uranie/tools/mdriva2008/root5.32.01/ROOT/lib/libCore.so.5.32).
This is the entire stack trace of all threads:

Thread 2 (Thread -1265038448 (LWP 10200)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d7f14e in sem_wait
GLIBC_2.0 () from /lib/i686/libpthread.so.0
#2 0xb7e4a688 in PyThread_acquire_lock () from /usr/lib/libpython2.5.so.1.0
#3 0xb7e28c59 in PyEval_RestoreThread () from /usr/lib/libpython2.5.so.1.0
#4 0xb4eaed85 in ?? () from /usr/lib/python2.5/lib-dynload/time.so
#5 0xb7ddd8e7 in PyCFunction_Call () from /usr/lib/libpython2.5.so.1.0
#6 0xb7e270eb in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#7 0xb7e28a75 in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#8 0xb7dcc205 in ?? () from /usr/lib/libpython2.5.so.1.0
#9 0xb7dadab9 in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#10 0xb7e25557 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#11 0xb7e27359 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#12 0xb7e28a75 in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#13 0xb7dcc281 in ?? () from /usr/lib/libpython2.5.so.1.0
#14 0xb7dadab9 in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#15 0xb7db5135 in ?? () from /usr/lib/libpython2.5.so.1.0
#16 0xb7dadab9 in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#17 0xb7e20bef in PyEval_CallObjectWithKeywords () from /usr/lib/libpython2.5.so.1.0
#18 0xb7e4e932 in ?? () from /usr/lib/libpython2.5.so.1.0
#19 0xb7d79462 in start_thread () from /lib/i686/libpthread.so.0
#20 0xb7cd582e in clone () from /lib/i686/libc.so.6

Thread 1 (Thread -1212184880 (LWP 10190)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7c958eb in waitpid () from /lib/i686/libc.so.6
#2 0xb7c3c15b in ?? () from /lib/i686/libc.so.6
#3 0xb7c3c552 in system () from /lib/i686/libc.so.6
#4 0xb7d811cd in system () from /lib/i686/libpthread.so.0
#5 0xb62a08dd in TUnixSystem::Exec () from /home/uranie/tools/mdriva2008/root5.32.01/ROOT/lib/libCore.so.5.32
#6 0xb62a84aa in TUnixSystem::StackTrace () from /home/uranie/tools/mdriva2008/root5.32.01/ROOT/lib/libCore.so.5.32
#7 0xb62a4daa in TUnixSystem::DispatchSignals () from /home/uranie/tools/mdriva2008/root5.32.01/ROOT/lib/libCore.so.5.32
#8 0xb62a4e9d in SigHandler () from /home/uranie/tools/mdriva2008/root5.32.01/ROOT/lib/libCore.so.5.32
#9 0xb629dcdd in sighandler () from /home/uranie/tools/mdriva2008/root5.32.01/ROOT/lib/libCore.so.5.32
#10
#11 0xb6279bfd in TClassRef::InternalGetClass () from /home/uranie/tools/mdriva2008/root5.32.01/ROOT/lib/libCore.so.5.32
#12 0xb7a54a70 in PyROOT::(anonymous namespace)::mp_call () from /home/uranie/tools/mdriva2008/root5.32.01/ROOT/lib/libPyROOT.so
#13 0xb7dadab9 in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#14 0xb7e25274 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#15 0xb7e28a75 in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#16 0xb7e28bd3 in PyEval_EvalCode () from /usr/lib/libpython2.5.so.1.0
#17 0xb7e417e8 in ?? () from /usr/lib/libpython2.5.so.1.0
#18 0xb7e418b7 in PyRun_FileExFlags () from /usr/lib/libpython2.5.so.1.0
#19 0xb7e42f8f in PyRun_SimpleFileExFlags () from /usr/lib/libpython2.5.so.1.0
#20 0xb7e436d8 in PyRun_AnyFileExFlags () from /usr/lib/libpython2.5.so.1.0
#21 0xb7e4c80e in Py_Main () from /usr/lib/libpython2.5.so.1.0
#22 0x08048581 in main ()
#0 0xffffe410 in __kernel_vsyscall ()

The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
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.

#11 0xb6279bfd in TClassRef::InternalGetClass () from /home/uranie/tools/mdriva2008/root5.32.01/ROOT/lib/libCore.so.5.32
#12 0xb7a54a70 in PyROOT::(anonymous namespace)::mp_call () from /home/uranie/tools/mdriva2008/root5.32.01/ROOT/lib/libPyROOT.so
#13 0xb7dadab9 in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#14 0xb7e25274 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#15 0xb7e28a75 in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#16 0xb7e28bd3 in PyEval_EvalCode () from /usr/lib/libpython2.5.so.1.0
#17 0xb7e417e8 in ?? () from /usr/lib/libpython2.5.so.1.0
#18 0xb7e418b7 in PyRun_FileExFlags () from /usr/lib/libpython2.5.so.1.0
#19 0xb7e42f8f in PyRun_SimpleFileExFlags () from /usr/lib/libpython2.5.so.1.0
#20 0xb7e436d8 in PyRun_AnyFileExFlags () from /usr/lib/libpython2.5.so.1.0
#21 0xb7e4c80e in Py_Main () from /usr/lib/libpython2.5.so.1.0
#22 0x08048581 in main ()
#0 0xffffe410 in __kernel_vsyscall ()
===========================================================[/quote]

Thank you for your help

Hi,

the difference between the releases is that the later releases touch “h” internally in case a life line needs to be setup to an object data member (not the case here). However, the method call deletes the object underneath h and so when it is touched after the call, things go badly wrong.

Very subtle, I say.

As a quick workaround, Clone() the histogram:h.Clone().DrawNormalized()
I’ll check in an actual fix in v5-34-patches, and trunk.

Cheers,
Wim

Hi Wim,

Thank you for your reply. The workaroud solved my problem.

Thanks,
Simon