TTree CopyTree causes segmentation fault on LSF

Hello!

I’ve encountered a strange problem with a function “CopyTree”. My macro (test.C in attachment) when run on lxplus machine directly goes well without any problems whatsoever. But when run on batch (LSF) it produces a segmentation fault at “CopyTree” instruction.
Do you have any idea what might be the problem? Or am I using it incorrectly?

My macro:
test.C (1.84 KB)

Compilation and execution (in bash):

[code]main="/afs/cern.ch/user/[your_path]"
code={main}"/source" bin={main}"/bin"
exe=“tests”

cd ${main}

ROOTCFLAGS=(root-config --cflags) ROOTLDFLAGS=(root-config --ldflags)
ROOTLIBS=(root-config --libs) ROOTGLIBS=(root-config --glibs)
OTHER="-fPIC -pipe -pthread -Wall -Wextra"

g++ {OTHER} {ROOTCFLAGS} {ROOTLIBS} -lrt {code}/testy.C -o {bin}/{exe}

if [ $? -ne 0 ] ; then
echo Compilation failed
exit 1
else
echo Compilation suceeded
fi

chmod +x {bin}/{exe}
./bin/${exe}[/code]

Best,
Maciej

Hi Maciej,

The problem is that:[code] Int_t evN;
Float_t p;

events->Branch("evN",&evN,"evN/I");
events->Branch("p",&p,"p/F");

[/code]associates local variable to the TTree. At the end of the function the TTree still remember this addresses and reuse them in the next function even though they are now invalid. [The case where you see a success is ‘just’ by chance]

To solve the problem add:events->ResetBranchAddresses();at the end of the FillTree function.

Cheers,
Philippe.

PS. Also (by unrelated) you are missing the pointer initialization in the constructor.

Dear Philippe,

Thank you for a response!
I tried adding the line you suggested, but it didn’t help and once again I’m obtaining a segmentation fault while executing on LSF batch (while no error when executed locally on lxplus).

I will try to get someone else to replicate that behavior.

Best,
Maciej

Hi,

One thing you can try is to run your test under valgrind, for example:valgrind --suppressions=$ROOTSYS/etc/valgrind-root.supp name_of_executable args

If this is a memory access issue, it might be able to detect it.

Cheers,
Philippe.

Hello again,

I tried running it with valgrind. Here is the output from lxplus:

==12992== HEAP SUMMARY: ==12992== in use at exit: 412,276,510 bytes in 236,606 blocks ==12992== total heap usage: 541,245 allocs, 304,639 frees, 761,966,315 bytes allocated ==12992== ==12992== LEAK SUMMARY: ==12992== definitely lost: 5,750,784 bytes in 9,984 blocks ==12992== indirectly lost: 394,466,856 bytes in 149,426 blocks ==12992== possibly lost: 5,174,539 bytes in 559 blocks ==12992== still reachable: 5,243,333 bytes in 62,162 blocks ==12992== suppressed: 1,640,998 bytes in 14,475 blocks ==12992== Rerun with --leak-check=full to see details of leaked memory ==12992== ==12992== For counts of detected and suppressed errors, rerun with: -v ==12992== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 43 from 16)
Is there anything suspicious here?
There is unfortunately no valgrind on LSF batch.

Best,
Maciej

Dear Philippe,

I have found the problem and it was silly. I had a default environment settings changing my root versions.
Running root-config --cflags I should have seen: -pthread -m64 -I/usr/include/root
And in my case it was -pthread -m64 -I/afs/cern.ch/sw/lcg/app/releases/ROOT/5.34.19/x86_64-slc6-gcc46-opt/root/include
And since it was in my .bashrc and not on LSF batch I got the error.

Thank you for the help and sorry for troubles!

Best,
Maciej