TTree of struct crashes on destructor while reading

ROOT
#1

Hi,
I’m creating a TTree with a struct like:
gROOT.ProcessLine(

“struct roides_t {
Int_t index;
Int_t event;
Int_t step;
Int_t rerun;
Float_t weight;
Float_t etamin ;
Float_t etamax ;
Float_t phimin ;
Float_t phimax ;
Char_t algoname[100];
};”
);

Then I read the TFile with:

def validate():
file = TFile(“feature.root”,“read”)
roides_tree = file.Get( ‘RoIDesTree’ )
roides = roides_t()
roides_tree.SetBranchAddress( “RoIDes”, AddressOf( roides, ‘index’ ))
entries = roides_tree.GetEntries()

print "Found %d entries"%entries
nb = roides_tree.GetEntry( 6 )
print "End of validate, close files"
#file.Write()
file.Close()
print "End of validate, close files closed"

if name == ‘main’:
validate()

With this function defined, I have a crash in the Tclass dst (from gdb):

#2 0x00007ffff45e8636 in TClass::Destructor(void*, bool) () from /afs/cern.ch/atlas/software/releases/20.2.3/LCGCMT/LCGCMT_71/InstallArea/x86_64-slc6-gcc48-opt/lib/libCore.so
#3 0x00007ffff735740b in PyROOT::op_dealloc_nofree(PyROOT::ObjectProxy*) ()

But if everything that is in validate() is moved in the main explicitly, the crash is not happening. I’ve added the file and the code to this entry.
I’m using:
Python 2.7.6 (default, Jul 8 2014, 13:33:49) [GCC 4.8.1] on linux2
ROOT 5.34/24

Please can you help me to understand where the memory corruption is happening?
Cheers
Francesca
test.py (1.13 KB)
feature.root (18.3 KB)

#2

The I run your python script I get:

Traceback (most recent call last):
  File "test.py", line 7, in <module>
    import rootpy
  File "/Users/couet/git/roottrunk-bin/lib/ROOT.py", line 301, in _importhook
    return _orig_ihook( name, *args, **kwds )
ImportError: No module named rootpy
#3

Hi,
I’m using some ATLAS setup. You can try to replace that line with:
import libPyROOT

Cheers
francesca

#4

Thanks.
How do you run this script … I still get some strange messages.

#5

I run as usual:

[fpastore@lxplus047] >python test.py
Found 97 entries
End of validate, close files
End of validate, close files closed

… and then hung!

or in gdb:

[fpastore@lxplus047] >gdb python
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-83.el6)
Copyright © 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and “show warranty” for details.
This GDB was configured as “x86_64-redhat-linux-gnu”.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/…
Reading symbols from /usr/bin/python…(no debugging symbols found)…done.
Missing separate debuginfos, use: debuginfo-install python-2.6.6-64.el6.x86_64
(gdb) run test.py
Starting program: /usr/bin/python test.py
[Thread debugging using libthread_db enabled]
Detaching after fork from child process 26783.
[New Thread 0x7fffedc44700 (LWP 26789)]
Found 97 entries
End of validate, close files
End of validate, close files closed

Program received signal SIGSEGV, Segmentation fault.
0x0000003b07e788bd in _int_free () from /lib64/libc.so.6
(gdb) where
#0 0x0000003b07e788bd in _int_free () from /lib64/libc.so.6
#1 0x0000003b08f77e9a in G__calldtor () from /usr/lib64/root/libCint.so.5.34
#2 0x00007ffff11eba87 in TClass::Destructor(void*, bool) () from /usr/lib64/root/libCore.so.5.34
#3 0x00007ffff19cf66b in PyROOT::op_dealloc_nofree(PyROOT::ObjectProxy*) ()
from /usr/lib64/python2.6/site-packages/libPyROOT.so
#4 0x00007ffff19cf6a9 in ?? () from /usr/lib64/python2.6/site-packages/libPyROOT.so
#5 0x0000003b09a9a705 in ?? () from /usr/lib64/libpython2.6.so.1.0
#6 0x0000003b09ad278d in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#7 0x0000003b09ad6b7f in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#8 0x0000003b09ad7647 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0
#9 0x0000003b09ad7722 in PyEval_EvalCode () from /usr/lib64/libpython2.6.so.1.0
#10 0x0000003b09af1b9c in ?? () from /usr/lib64/libpython2.6.so.1.0
#11 0x0000003b09af1c70 in PyRun_FileExFlags () from /usr/lib64/libpython2.6.so.1.0
#12 0x0000003b09af315c in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.6.so.1.0
#13 0x0000003b09aff892 in Py_Main () from /usr/lib64/libpython2.6.so.1.0
#14 0x0000003b07e1ed5d in __libc_start_main () from /lib64/libc.so.6
#15 0x0000000000400649 in _start ()

Cheers
f

#6

Ah ok … it looks fine for me. On Mac, both ROOT 6.07/03 and 5.34/35 give me:

$ python test.py 
Found 97 entries
End of validate, close files
End of validate, close files closed
$

… no “hung”.

#7

Hmmm, I’m on lxplus:
Python 2.6.6
ROOT 5.34/32

which python are you using?
f

#8 
$ python --version
Python 2.7.10

But I am not a python expert … I will ask a colleague who might have more hints.

#9

Hi Francesca,

I tried to reproduce your script on lxplus using these instructions to set up root*. The script also needs rootpy, can you give us a recipe to set up an environment equivalent to yours (I know you probably set up the atlas environment)?

D

root.cern.ch/content/release-53432

#10

Hi,
I’m not sourcing any ATLAS setup, and I commented out all settings in the .bash_profile, then:
-bash-4.1$ which root
/usr/bin/root
(which is ROOT 5.34/32)
-bash-4.1$ python --version
Python 2.6.6

No idea of where the settings are coming from (no ROOTSYS is set), probably the default lxplus bash configuration??

Cheers
f

#11

Hi Francesca,

I got confused by

thanks for clarifying. How do I get the rootpy version you are using?

D

#12

no idea… I just do the import in the file I sent you. I didn’t install any rootpy by myself…
How can I guess it?
f

#13

Hi,

it must be in your environment.
Do you see any hint in the output of

python -v test.py

Cheers,
D

#14

Hi,
no “root” string found in the output of your command.
Anyhow, while doing other make-ups, I discovered that I fill the char[100] variable in the structure with a string that in some cases is shorter than 100, and this is probably the reason of my crash in reading it back (some memory corruption…). Fixed it, I don’t have any problem.
Strange that you don’t see the crash, while I do.
It would be anyhow nice to know which rootpy version I’m using, just for reference in next dev.

Cheers
francesca

#15

Not is problem some case shorter, is problem many case longer. TTree simply return pointer, PyROOT simply eat pointer: but is tell size 100. Not true! Size is 102 most case. Check bytes read return GetEntry().

Because is memory overwrite, some see crash, some no. Is depend hit important bytes or no.

-Dom

#16

Hi Dominique,
I found indeed an overwrite when producing the tuple. Problem is solved.
Thanks.
Cheers
francesca