Problem with TTree::~TTree()

exaos · September 18, 2003, 9:57pm

Version: 3.05/07 (compiled from source codes)
Platform: RedHat Linux 8.0 with gcc 3.2.2

Please help me to check my script. I got a segmentation violation each time I ran it. When I turned trace on, root told me something like this:

!!!Calling destructor 0x8b455c0.~TTree() for dE_E ary0:link-1
* Break * segmentation violation
Generating stack trace…
0x401e3bc7 in TUnixSystem::StackTrace() at /sci/root/src/v3.05.07/unix/src/TUnixSystem.cxx:1496 from /sci/root/current/lib/libCore.so
0x401e256b in TUnixSystem::DispatchSignals(ESignals) at /sci/root/src/v3.05.07/unix/src/TUnixSystem.cxx:697 from /sci/root/current/lib/libCore.so
0x401e1531 in from /sci/root/current/lib/libCore.so
0x401e5798 in from /sci/root/current/lib/libCore.so
0x40e4c911 in from /lib/libpthread.so.0
0x40f93cb8 in from /lib/libc.so.6
0x40fdbea6 in __libc_free + 0x96 from /lib/libc.so.6
0x40f1ade3 in operator delete(void) at /usr/src/build/146482-i386/BUILD/gcc-3.2-20020903/obj-i386-redhat-linux/i386-redhat-linux/libstdc+± from /usr/lib/libstdc++.so.5
0x400e35a0 in TAttLine::~TAttLine in-charge deleting at /sci/root/src/v3.05.07/base/src/TAttLine.cxx:67 from /sci/root/current/lib/libCore.so
0x40d09840 in from /sci/root/current/lib/libTree.so
0x405cf1e6 in G__call_cppfunc at /sci/root/src/v3.05.07/cint/src/newlink.c:502 from /sci/root/current/lib/libCint.so
0x405bba70 in G__interpret_func at /sci/root/src/v3.05.07/cint/src/ifunc.c:6428 from /sci/root/current/lib/libCint.so
0x4059b26c in Ggetfunction at /sci/root/src/v3.05.07/cint/src/func.c:2045 from /sci/root/current/lib/libCint.so
0x40584d10 in Gdestroy at /sci/root/src/v3.05.07/cint/src/end.c:574 from /sci/root/current/lib/libCint.so
0x40584995 in Gdestroy at /sci/root/src/v3.05.07/cint/src/end.c:483 from /sci/root/current/lib/libCint.so
0x40584995 in Gdestroy at /sci/root/src/v3.05.07/cint/src/end.c:483 from /sci/root/current/lib/libCint.so
0x405be873 in G__interpret_func at /sci/root/src/v3.05.07/cint/src/ifunc.c:7893 from /sci/root/current/lib/libCint.so
0x4059bb24 in Ggetfunction at /sci/root/src/v3.05.07/cint/src/func.c:2348 from /sci/root/current/lib/libCint.so
0x40592611 in Ggetitem at /sci/root/src/v3.05.07/cint/src/expr.c:2119 from /sci/root/current/lib/libCint.so
0x40590d66 in Ggetexpr at /sci/root/src/v3.05.07/cint/src/expr.c:1503 from /sci/root/current/lib/libCint.so
0x405e8f75 in Gexec_function at /sci/root/src/v3.05.07/cint/src/parse.c:513 from /sci/root/current/lib/libCint.so
0x405f1a77 in G__exec_statement at /sci/root/src/v3.05.07/cint/src/parse.c:4600 from /sci/root/current/lib/libCint.so
0x40574cd2 in G__exec_tempfile_core at /sci/root/src/v3.05.07/cint/src/debug.c:390 from /sci/root/current/lib/libCint.so
0x40574eba in G__exec_tempfile_fp at /sci/root/src/v3.05.07/cint/src/debug.c:472 from /sci/root/current/lib/libCint.so
0x405fb846 in G__process_cmd at /sci/root/src/v3.05.07/cint/src/pause.c:3860 from /sci/root/current/lib/libCint.so
0x4017b211 in TCint::ProcessLine(char const, TInterpreter::EErrorCode) at /sci/root/src/v3.05.07/meta/src/TCint.cxx:263 from /sci/root/current/lib/libCore.so
0x400e020c in TApplication::ProcessLine(char const, bool, int*) at /sci/root/src/v3.05.07/base/src/TApplication.cxx:659 from /sci/root/current/lib/libCore.so
0x40e0ae88 in TRint::HandleTermInput() at /sci/root/src/v3.05.07/rint/src/TRint.cxx:362 from /sci/root/current/lib/libRint.so
0x40e0969c in TTermInputHandler::Notify() at /sci/root/src/v3.05.07/rint/src/TRint.cxx:101 from /sci/root/current/lib/libRint.so
0x40e0baa0 in TTermInputHandler::ReadNotify() at /sci/root/src/v3.05.07/rint/src/TRint.cxx:95 from /sci/root/current/lib/libRint.so
0x401e290c in TUnixSystem::CheckDescriptors() at /sci/root/src/v3.05.07/unix/src/TUnixSystem.cxx:805 from /sci/root/current/lib/libCore.so
0x401e211d in TUnixSystem::DispatchOneEvent(bool) at /sci/root/src/v3.05.07/unix/src/TUnixSystem.cxx:611 from /sci/root/current/lib/libCore.so
0x401425a5 in TSystem::InnerLoop() at /sci/root/src/v3.05.07/base/src/TSystem.cxx:303 from /sci/root/current/lib/libCore.so
0x40142529 in TSystem::Run() at /sci/root/src/v3.05.07/base/src/TSystem.cxx:271 from /sci/root/current/lib/libCore.so
0x400e0ad3 in TApplication::Run(bool) at /sci/root/src/v3.05.07/base/src/TApplication.cxx:768 from /sci/root/current/lib/libCore.so
0x40e0a900 in TRint::Run(bool) at /sci/root/src/v3.05.07/rint/src/TRint.cxx:243 from /sci/root/current/lib/libRint.so
0x0804884b in main + 0xb7 from /sci/root/build/v3.05.07/bin/root.exe
0x40f824ad in __libc_start_main + 0xa9 from /lib/libc.so.6
0x08048705 in _Unwind_Resume + 0x31 from /sci/root/build/v3.05.07/bin/root.exe
Root > Function qfs_classify() busy flag cleared

run98%2.root (580 KB)
qfs_classify.C (2.26 KB)

brun · September 19, 2003, 8:43am

You are creating the Trees and the files in the stack. When you leave the scope of your function, these objects will be destroyed in an unpredictible order. Using objects in the heap, then an explicit delete removes this difficulty.
In your case, you can also instruct the Trees to forget about their files in adding the following statements at the end of your function after "dE_E.Print();

//We do not know in which order the files and Trees will be deleted
//We better disconnect the trees from the files now
qfs.SetDirectory(0); //<==========
monitor.SetDirectory(0); //<==========
dE_E.SetDirectory(0); //<==========

Rene

exaos · September 20, 2003, 3:59pm

Yes. TTree::SetDirectory() does work!
I often get confused by heap and stack. Though I try to ignore using pointer as possible, I often get segmentation violation.

Thank you.