Segmentation fault in a program reading a TTree

Hello,
I have a TTree in a root file which I want to read for an analysis. In one of the branches the TTree holds objects of an ‘user defined’ class.
The tree is working just fine: I can do everything using the ROOT Cint (i.e. using a macro). The problem arise when I try to run a program to carry out the tasks: It always gives a segmentation fault when it tries to access to the TTree’s entries (i.e. using GetEntry()):

*** Break *** segmentation violation Attaching to program: /proc/19829/exe, process 19829 [Thread debugging using libthread_db enabled] [New Thread 0xb4ba98d0 (LWP 19829)] 0xb7efd410 in __kernel_vsyscall () #1 0xb4c414d3 in waitpid () from /lib/tls/i686/cmov/libc.so.6 #2 0xb4be4643 in ?? () from /lib/tls/i686/cmov/libc.so.6 #3 0xb4d08d7d in system () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb69c52fd in TUnixSystem::Exec () from /cern/root/lib/libCore.so #5 0xb69ca636 in TUnixSystem::StackTrace () from /cern/root/lib/libCore.so #6 0xb69c95a6 in TUnixSystem::DispatchSignals () from /cern/root/lib/libCore.so #7 0xb69c968d in SigHandler () from /cern/root/lib/libCore.so #8 0xb69c26dd in sighandler () from /cern/root/lib/libCore.so #9 <signal handler called> #10 0x0813ddc0 in _GLOBAL_OFFSET_TABLE_ () #11 0xb5ffbf80 in TStreamerInfo::ReadBuffer<char**> () from /cern/root/lib/libRIO.so #12 0xb5538f51 in TBranchElement::ReadLeaves () from /cern/root/lib/libTree.so #13 0xb552ec33 in TBranch::GetEntry () from /cern/root/lib/libTree.so #14 0xb5534c38 in TBranchElement::GetEntry () from /cern/root/lib/libTree.so #15 0xb5534bba in TBranchElement::GetEntry () from /cern/root/lib/libTree.so #16 0xb5534bba in TBranchElement::GetEntry () from /cern/root/lib/libTree.so #17 0xb5534bba in TBranchElement::GetEntry () from /cern/root/lib/libTree.so #18 0xb5534bba in TBranchElement::GetEntry () from /cern/root/lib/libTree.so #19 0xb5583afa in TTree::GetEntry () from /cern/root/lib/libTree.so #20 0xb554b16a in TChain::GetEntry () from /cern/root/lib/libTree.so #21 0x080584ac in main (argc=2, argv=0x0) at KsRec.cc:40 The program is running. Quit anyway (and detach it)? (y or n) [answered Y; input not from terminal] Detaching from program: /proc/19829/exe, process 19829
I have attached a tar file with the program itself. There you can find a macro called analysis.C which is working just perfect, and a program called KsRec.cc which pretends to do exactly the same, but it crashes giving the segmentation fault. I compile and link the program with no errors (I have included all the particular headers and shared libraries that the program needs).
Unfortunately, you won’t be able neither to compile nor run the program. But I would be very grateful if somebody has an idea or a clue about why the program fails.

Thanks!
KsRec.tar.gz (260 Bytes)

I forgot to mention something important:
I got the segmentation fault with ROOT 5.18 and 5.20.
If I re-compile everything with ROOT 5.14, then the program works perfect!
:open_mouth:

Hi,

If do not see your source file in the tar file you uploaded.

The problem is most likely the way you set the address of the branch (there is a few way to ‘break’ it, so your source file would be needed for a better diagnosis). It might be that you set the address to the wrong type of object or set it to point a variable that is gone out of scope by the time you do the GetEntry (those are not the only possibilities).

Cheers,
Philippe

I don’t Know what happened. Here you have the correct tar.

Thank you
KsRec.tar.gz (2.67 KB)

Hi,

You have: uDSTParticleInfo *EventInfo; chain->SetBranchAddress("EventInfo", &EventInfo);which should read uDSTParticleInfo *EventInfo = 0; chain->SetBranchAddress("EventInfo", &EventInfo);.
If this does not fix the problem, I would need enough file/information to fully reproduce your problem.

Cheers,
Philippe.

Fortunately it does!! Thank you very much!
Why then it works with CINT and ROOT 5.14?

[quote]Why then it works with CINT and ROOT 5.14?[/quote]You did not initialize your variable, so the behavior is random/unpredictable. In other you got lucky :slight_smile:.

Cheers,
Philippe.