PyROOT segfault on ROOT.TFile() with ROOT6

Documentation here: github.com/rootpy/root_numpy/pull/165

Specifically, when one runs

[code]>>> from ROOT import TFile

f = TFile.Open(‘single1.root’)

f
<ROOT.TFile object (“single1.root”) at 0x409a0d0>

f = TFile()
f

*** Break *** segmentation violation
[/code]

the stack trace (via gdb) is

[code]===========================================================
There was a crash (kSigSegmentationViolation).
This is the entire stack trace of all threads:

Thread 2 (Thread 0x7f21c0912700 (LWP 6088)):
#0 sem_wait () at …/nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
#1 0x00000000005bc117 in ?? ()
#2 0x00000000004caa35 in PyEval_EvalFrameEx ()
#3 0x00000000004e6970 in ?? ()
#4 0x00000000004cd00f in PyEval_EvalFrameEx ()
#5 0x00000000004cb212 in PyEval_EvalFrameEx ()
#6 0x00000000004cb212 in PyEval_EvalFrameEx ()
#7 0x00000000004e6970 in ?? ()
#8 0x0000000000505128 in ?? ()
#9 0x00000000004d25fb in PyEval_CallObjectWithKeywords ()
#10 0x00000000005bbc82 in ?? ()
#11 0x00007f21cf2c50a5 in start_thread (arg=0x7f21c0912700) at pthread_create.c:309
#12 0x00007f21ceff277d in clone () at …/sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7f21cf6d2740 (LWP 6075)):
#0 0x00007f21cefb94e9 in __libc_waitpid (pid=6099, stat_loc=stat_loc
entry=0x7fff640247f0, options=options
entry=0) at …/sysdeps/unix/sysv/linux/waitpid.c:40
#1 0x00007f21cef3c7d2 in do_system (line=) at …/sysdeps/posix/system.c:148
#2 0x00007f21cd336c34 in TUnixSystem::Exec (this=0x248b980, shellcmd=0x3e15400 “/home/endw/software/root/root_v6.02/etc/root/gdb-backtrace.sh 6075 1>&2”) at /home/endw/software/root/root/core/unix/src/TUnixSystem.cxx:2069
#3 0x00007f21cd3374de in TUnixSystem::StackTrace (this=0x248b980) at /home/endw/software/root/root/core/unix/src/TUnixSystem.cxx:2297
#4 0x00007f21cd33b02b in TUnixSystem::DispatchSignals (this=0x248b980, sig=kSigSegmentationViolation) at /home/endw/software/root/root/core/unix/src/TUnixSystem.cxx:3533
#5 0x00007f21cd332e43 in SigHandler (sig=kSigSegmentationViolation) at /home/endw/software/root/root/core/unix/src/TUnixSystem.cxx:395
#6 0x00007f21cd33af7a in sighandler (sig=11) at /home/endw/software/root/root/core/unix/src/TUnixSystem.cxx:3510
#7
#8 0x00007f21ccaad613 in TDirectoryFile::Get (this=0x42340e0, namecycle=0x2ef3418 “deref”) at /home/endw/software/root/root/io/io/src/TDirectoryFile.cxx:868
#9 0x00007f21c77639e5 in ?? ()
#10 0x00007fff64027a60 in ?? ()
#11 0x00007fff64027be0 in ?? ()
#12 0x00007fff640279f8 in ?? ()
#13 0x00000001c821699c in ?? ()
#14 0x00000000042340e0 in ?? ()
#15 0x00007f21c77639a0 in ?? ()
#16 0x00007fff64027cb0 in ?? ()
#17 0x00007f21c8211779 in TClingCallFunc::exec (this=0x414c9e0, address=0x42340e0, ret=0x7fff64027be0) at /home/endw/software/root/root/core/meta/src/TClingCallFunc.cxx:1873
#18 0x00007f21c8211bf9 in TClingCallFunc::exec_with_valref_return (this=0x414c9e0, address=0x42340e0, ret=0x7fff64027be0) at /home/endw/software/root/root/core/meta/src/TClingCallFunc.cxx:1936
#19 0x00007f21c82170dc in TClingCallFunc::ExecT (this=0x414c9e0, address=0x42340e0) at /home/endw/software/root/root/core/meta/src/TClingCallFunc.cxx:2130
#20 0x00007f21c8212499 in TClingCallFunc::ExecInt (this=0x414c9e0, address=0x42340e0) at /home/endw/software/root/root/core/meta/src/TClingCallFunc.cxx:2143
#21 0x00007f21c81563dc in TCling::CallFunc_ExecInt (this=0x24d64c0, func=0x414c9e0, address=0x42340e0) at /home/endw/software/root/root/core/meta/src/TCling.cxx:6060
#22 0x00007f21cd7a1b6e in PRCallFuncExecInt (func=0x1c821699c, self=0x7fff640279f8, release_gil=255) at /home/endw/software/root/root/bindings/pyroot/src/Executors.cxx:51

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

#8 0x00007f21ccaad613 in TDirectoryFile::Get (this=0x42340e0, namecycle=0x2ef3418 “deref”) at /home/endw/software/root/root/io/io/src/TDirectoryFile.cxx:868
#9 0x00007f21c77639e5 in ?? ()
#10 0x00007fff64027a60 in ?? ()
#11 0x00007fff64027be0 in ?? ()
#12 0x00007fff640279f8 in ?? ()
#13 0x00000001c821699c in ?? ()
#14 0x00000000042340e0 in ?? ()
#15 0x00007f21c77639a0 in ?? ()
#16 0x00007fff64027cb0 in ?? ()
#17 0x00007f21c8211779 in TClingCallFunc::exec (this=0x414c9e0, address=0x42340e0, ret=0x7fff64027be0) at /home/endw/software/root/root/core/meta/src/TClingCallFunc.cxx:1873
#18 0x00007f21c8211bf9 in TClingCallFunc::exec_with_valref_return (this=0x414c9e0, address=0x42340e0, ret=0x7fff64027be0) at /home/endw/software/root/root/core/meta/src/TClingCallFunc.cxx:1936
#19 0x00007f21c82170dc in TClingCallFunc::ExecT (this=0x414c9e0, address=0x42340e0) at /home/endw/software/root/root/core/meta/src/TClingCallFunc.cxx:2130
#20 0x00007f21c8212499 in TClingCallFunc::ExecInt (this=0x414c9e0, address=0x42340e0) at /home/endw/software/root/root/core/meta/src/TClingCallFunc.cxx:2143
#21 0x00007f21c81563dc in TCling::CallFunc_ExecInt (this=0x24d64c0, func=0x414c9e0, address=0x42340e0) at /home/endw/software/root/root/core/meta/src/TCling.cxx:6060
#22 0x00007f21cd7a1b6e in PRCallFuncExecInt (func=0x1c821699c, self=0x7fff640279f8, release_gil=255) at /home/endw/software/root/root/bindings/pyroot/src/Executors.cxx:51

<ROOT.TFile object at 0x42340e0>

[/code]

Had some thoughts such as: PyROOT wasn’t compiled against the correct ROOT version (checked). What is potentially even stranger is running PyROOT from within ROOT6 doesn’t segfault:

gSystem->Load( "libPyROOT" ); TPython::Exec("print1+1"); TFile* f = (void*)TPython::Eval("ROOT.TFile()");

as that code runs fine.

Some other code that we ran for funsies to see what was going on but ended up confusing us more…

[code]>>> ROOT.TTree()
<ROOT.TTree object at 0x2c49db0>

ROOT.TChain()
<ROOT.TChain object at 0x2d26b60>

ROOT.TFile()

*** Break *** segmentation violation
[/code]

It turns out that the same error persists in 5.34 – so it’s been raised to here: sft.its.cern.ch/jira/browse/ROOT-7005

Hi,

is a problem with the printing only, which checks for the existence of deref, in case it is dealing with a smart pointer object. But the TFile has a getattr that then forwards that lookup.

Will fix, but am doing a major refactoring in master, which has priority.

Cheers,
Wim