SegFault in Compiled Macro due to SetBranchAddress

Hi all,

My issue is a bit complicated, but I am going to try to keep it simple and clear. I have an analysis macro which I would like to have working on 3 different computers. When running this interactively (.L macro.C, runMacro()), I have no issues on any of the machines. However, running interactively takes a long time, so I am trying to compile it (.L macro.C+, runMacro()).

On one machine (gcc version 4.4.1(Ubuntu 4.4.1-4ubuntu9) + ROOT 5.26.00 ), the code compiles and runs correctly. On the other two machines, the code “successfully” compiles, but seg faults when I try to run it. I have narrowed down the seg fault to the line “tree->GetEntry(i)”. In my macro, I set the status of all the branches of the ntuple to zero, then reactivate the ones I need (~30), and then use SetBranchAddress for these 30 branches. I have found that if I only set the address for one of these branches (and it does not matter which one), the code runs fine. If, however, I try to set the address for more than one, the seg fault appears.

Since this problem is machine dependent, my first guess is a compiler issue. One of the two failing machines has access to /afs/, so I tried to set the compiler to the same version; the closest one I could get is gcc version 4.4.3 (GCC). I am also using the same version of ROOT on this machine. The only other important difference between this machine and the successful one is that the successful machine has a 32-bit processor, and the failing has a 64-bit.

Based on this information, can anyone point me towards what is going wrong?


PS: I have attached my macro to this post. The seg fault occurs at line 312; the relevant SetBranchAddress commands are on lines 221-251.
branchNames_private.txt (243 Bytes)
strCut.h (4.42 KB)
my_readD3PD.C (26.6 KB)


nice approach with the branch names! You need to set the data pointers to NULL or ROOT cannot know whether you have already allocated the objects or whether you want ROOT to allocate them for you. Because they are random, they are usually != 0, and thus ROOT assumes that they point to a valid object and just puts the data there. I.e. what you are missing is vector *el_e = 0; etc.

Cheers, Axel.

Hi Axel,

That solution works perfectly. Thanks a lot.

Any guesses as to why this problem would not manifest on the one machine where the code already worked? Did I just get “lucky” that the random memory allocation ended up being correct?

Thanks again,


[quote]Did I just get “lucky” that the random memory allocation ended up being correct?[/quote]Yup, one of common random value is ‘0’ :slight_smile:.