Macro reading TTree doesn't work ROOT6.12

M.Bona · April 4, 2018, 3:09pm

Dear Rooters,
I wrote a macro to read entries from a given TTree and to perform different operations with them (from filling histograms to more complex operations such as fitting and filtering data) but when I try to execute it from my platform it crashes as follows:

 *** Break *** segmentation violation



===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
#0  0x00007febe529682a in waitpid () from /usr/lib/libc.so.6
#1  0x00007febe5214bcf in do_system () from /usr/lib/libc.so.6
#2  0x00007febe5e41a24 in TUnixSystem::StackTrace() () from /usr/lib/root/libCore.so
#3  0x00007febe5e4425e in TUnixSystem::DispatchSignals(ESignals) () from /usr/lib/root/libCore.so
#4  <signal handler called>
#5  0x00007febe3737097 in TBufferFile::ReadFastArray(double*, int) () from /usr/lib/root/libRIO.so
#6  0x00007febe383f0fd in int TStreamerInfoActions::VectorLooper::ReadCollectionBasicType<double>(TBuffer&, void*, TStreamerInfoActions::TConfiguration const*) () from /usr/lib/root/libRIO.so
#7  0x00007febe3735b44 in TBufferFile::ApplySequence(TStreamerInfoActions::TActionSequence const&, void*) () from /usr/lib/root/libRIO.so
#8  0x00007febd7bcc9f1 in TBranchElement::ReadLeavesMember(TBuffer&) () from /usr/lib/root/libTree.so
#9  0x00007febd7bbeeb2 in TBranch::GetEntry(long long, int) () from /usr/lib/root/libTree.so
#10 0x00007febd7bd844b in TBranchElement::GetEntry(long long, int) () from /usr/lib/root/libTree.so
#11 0x00007febd7c204f1 in TTree::GetEntry(long long, int) () from /usr/lib/root/libTree.so
#12 0x00007febe63cf321 in ?? ()
#13 0x000055e01217b860 in ?? ()
#14 0x00007ffe08c373e0 in ?? ()
#15 0x0000000000000001 in ?? ()
#16 0x00007febe52095a9 in msort_with_tmp.part () from /usr/lib/libc.so.6
#17 0x00000004e266ed5b in ?? ()
#18 0x0000000000000007 in ?? ()
#19 0x0000000000000040 in ?? ()
#20 0x0000000000000038 in ?? ()
#21 0x000055e0108ff020 in ?? ()
#22 0x0000000000000060 in ?? ()
#23 0x0000000000000002 in ?? ()
#24 0xffffffffffffbd50 in ?? ()
#25 0x0000000000000001 in ?? ()
#26 0x0000003100000004 in ?? ()
#27 0x0000000000000000 in ?? ()
===========================================================

But if I try to run it on lxplus (apparently) it works without any problem. If I check the root version running on lxplus, it is the 5.34/36 with CINT/ROOT C/C++ Interpreter version 5.18.00.
How can I solve it and run from my machine? The output I get from lxplus with root 5.34 is correct or does the macro run and produces an output with any possible problem?

Thanks for your help,
Matteo

ROOT Version (e.g. 6.12/06):
Platform, compiler (e.g. Manjaro Linux 64bit, gcc7.3.1):

pcanal · April 4, 2018, 5:36pm

This kind of stack trace usually indicates a C++ memory error. I recommend you try running your failing example under valgrind:

valgrind --suppressions=$ROOTSYS/etc/valgrind-root.supp name_of_you_execuable arguments

which might indicate what the problem is.

M.Bona · April 5, 2018, 7:21am

Dear pcnal,
Thank you for your suggestion. I tried to run the macro under valgrind but it doesn’t work, probably because I am trying to run a macro instead of a compiled program?
How do I explain that I have a possible C++ memory error on my machine but the macro runs on lxplus?

Wile_E_Coyote · April 5, 2018, 10:04am

pcanal · April 5, 2018, 2:33pm

Because memory error lead to ‘random’/‘undefined’ behavior which includes … looking like it works.

probably because I am trying to run a macro instead of a compiled program?

Then do

valgrind --suppressions=$ROOTSYS/etc/valgrind-root.supp root.exe -b -l -q macroName.C

or better yet make the macro compilable and do:

valgrind --suppressions=$ROOTSYS/etc/valgrind-root.supp root.exe -b -l -q macroName.C+

Cheers,
Philippe.

M.Bona · April 5, 2018, 3:39pm

I see… I am wondering if is it possible that I made some error during the installation of root on my machine that causes these errors or if for sure I can say the macro has bugs. I have this doubt because I had the same problem with other macros, not written by me, which should be correct and working well. Moreover, if I run those macro on lxplus I get the output I expect.

If I run

It brakes with the following output

FATAL: can't open suppressions file "/etc/valgrind-root.supp"

Thanks for your precious help,
Matteo

pcanal · April 5, 2018, 3:54pm

FATAL: can’t open suppressions file “/etc/valgrind-root.supp”

ROOTSYS is not set. Replace it with the top directory of your ROOT install.

I have this doubt because I had the same problem with other macros, not written by me, which should be correct and working well.

To test this, just do:

root.exe -b -l -q $ROOTSYS/tutorials/hsimple.C

if this fails then indeed your installation is problematic.

Cheers,
Philippe.

M.Bona · April 6, 2018, 7:12am

I run valgrind on hsimple.C and it returns the same errors I get when running it on my macro file. “Luckily” the results I obtained so far running my macro from lxplus are safe and everything depends on some problems with my installation of root.

Probably there is something faulty on the root AUR package, since I am running Manjaro Arch Linux and I have installed root from the aur repository. I will check it better.

Thanks for your help,
Matteo

sbinet · April 6, 2018, 9:23am

this is running fine, here, on my ArchLinux:

$> uname -a
Linux zoidberg 4.15.12-1-ARCH #1 SMP PREEMPT Wed Mar 21 15:14:56 UTC 2018 x86_64 GNU/Linux

$> pacman -Qi root
Name            : root
Version         : 6.12.06-2
Description     : C++ data analysis framework and interpreter from CERN.
Architecture    : x86_64
URL             : http://root.cern.ch
Licenses        : LGPL2.1
Groups          : None
Provides        : None
Depends On      : cfitsio  fftw  ftgl  gl2ps  glew  graphviz  gsl
                  hicolor-icon-theme  intel-tbb  libafterimage  libiodbc
                  libmariadbclient  postgresql-libs  python  sqlite
                  tex-gyre-fonts  unixodbc  unuran  xmlrpc-c
Optional Deps   : blas: Optional extensions to TMVA [installed]
                  fcgi: Language independent, high performant extension to CGI
                  go: Go language support [installed]
                  gcc-fortran: Enable the Fortran components of ROOT [installed]
                  ocaml: OCAML support
                  pythia: Pythia8 support
                  python-numpy: numpy bindings [installed]
                  tcsh: Legacy CSH support
                  xrootd: XRootD support
                  z3: Z3 Theorem prover support
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 290.37 MiB
Packager        : Unknown Packager
Build Date      : Mon 26 Mar 2018 10:16:57 PM CEST
Install Date    : Mon 26 Mar 2018 10:19:26 PM CEST
Install Reason  : Explicitly installed
Install Script  : Yes
Validated By    : None

(never had much problem with the ROOT package on ArchLinux, except it’s taking a damn awful time to recompile… the only time was when ArchLinux migrated to Py3 as the default python interpreter before Py3 support of ROOT was robust)

M.Bona · April 6, 2018, 1:04pm

@pcanal @sbinet actually you are right, everything works fine for me as well.
The problem is the following: if I simply run root.exe -b -l -q $ROOTSYS/tutorials/hsimple.C I do not encounter any problem, but if I run it using valgrind it crashes. Why is it so? In addition there is something I still can not figure out: I imagine the problem with my macro comes from the fact that on lxplus is running ROOT v5 while on my machine I have installed v6. Could it be?
All the instructions I am trying to execute with the macro seem fine (if I maintain the same structure but with more simple instructions it crashes anyway). May the problem come from the fact that I am reading a TTree with huge amount of data in it?

There is a person working on a Mac with these same macros I am using and she does not encounter any problem at all on running them (I should check which version of root she is running, but I assume it is the latest, as mine is).
If I write a simple macro just to read TTree branches it crashes when running on my machine but output seems fine from lxplup.

pcanal · April 6, 2018, 2:17pm

On the failing case do (and send the output of

which root
which root.exe
echo $ROOTSYS
echo $LD_LIBRARY_PATH
echo $PATH
ldd `which root.exe`
ldd path_name_to_you_exec_or_library
ls -l path_name_to_you_exec_or_library

also what is the ‘crash’ output when running hsimple with valgrind?

M.Bona · April 9, 2018, 7:16am

This is what I get if I run valgring on hsimple.C:

valgrind --suppressions=`root-config --etcdir`/valgrind-root.supp root.exe -b -l -q hsimple.C
==8871== Memcheck, a memory error detector
==8871== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==8871== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==8871== Command: root.exe -b -l -q hsimple.C
==8871== 
==8871== Conditional jump or move depends on uninitialised value(s)
==8871==    at 0x526F284: TInetAddress::TInetAddress() (in /usr/lib/root/libCore.so)
==8871==    by 0x537BEC5: TUnixSystem::GetHostByName(char const*) (in /usr/lib/root/libCore.so)
==8871==    by 0x52BDD01: TUUID::GetNodeIdentifier() (in /usr/lib/root/libCore.so)
==8871==    by 0x52BDFB2: TUUID::TUUID() (in /usr/lib/root/libCore.so)
==8871==    by 0x5284EDA: TProcessID::AddProcessID() (in /usr/lib/root/libCore.so)
==8871==    by 0x51C60A2: TROOT::TROOT(char const*, char const*, void (**)()) (in /usr/lib/root/libCore.so)
==8871==    by 0x51C6D46: ROOT::Internal::GetROOT1() (in /usr/lib/root/libCore.so)
==8871==    by 0x51B8D23: ??? (in /usr/lib/root/libCore.so)
==8871==    by 0x400F479: call_init.part.0 (in /usr/lib/ld-2.26.so)
==8871==    by 0x400F585: _dl_init (in /usr/lib/ld-2.26.so)
==8871==    by 0x4000F69: ??? (in /usr/lib/ld-2.26.so)
==8871==    by 0x4: ???
==8871== 
==8871== Conditional jump or move depends on uninitialised value(s)
[...]
Processing hsimple.C...
==8871== Conditional jump or move depends on uninitialised value(s)
==8871==    at 0x5320935: TClass::SetRuntimeProperties() (in /usr/lib/root/libCore.so)
==8871==    by 0x5320FF4: ROOT::Internal::HasConsistentHashMember(TClass&) (in /usr/lib/root/libCore.so)
==8871==    by 0x51C7548: TGlobal::CheckTObjectHashConsistency() const (in /usr/lib/root/libCore.so)
==8871==    by 0x52E7474: THashTable::Add(TObject*) (in /usr/lib/root/libCore.so)
==8871==    by 0x52E42A2: THashList::AddLast(TObject*) (in /usr/lib/root/libCore.so)
==8871==    by 0x5342571: TListOfDataMembers::AddLast(TObject*) (in /usr/lib/root/libCore.so)
==8871==    by 0x51BF3D9: TROOT::GetListOfGlobals(bool) (in /usr/lib/root/libCore.so)
==8871==    by 0x8573DD8: ??? (in /usr/lib/root/libCling.so)
==8871==    by 0x857A424: ??? (in /usr/lib/root/libCling.so)
==8871==    by 0x85F7957: ??? (in /usr/lib/root/libCling.so)
==8871==    by 0x866A1EE: cling::IncrementalParser::commitTransaction(llvm::PointerIntPair<cling::Transaction*, 2u, cling::IncrementalParser::EParseResult, llvm::PointerLikeTypeTraits<cling::Transaction*>, llvm::PointerIntPairInfo<cling::Transaction*, 2u, llvm::PointerLikeTypeTraits<cling::Transaction*> > >&, bool) (in /usr/lib/root/libCling.so)
==8871==    by 0x866A3BB: cling::IncrementalParser::Compile(llvm::StringRef, cling::CompilationOptions const&) (in /usr/lib/root/libCling.so)
==8871==

Which is more or less the same error message I get when I run valgrind on my macro.
I don’t get any error message if I simply run root.exe -b -l -q hsimple.C

pcanal · April 9, 2018, 5:15pm

Humm … those are potentially ‘spurrious’ and are not a ‘crash’ (at least not from the output I see).

To track down your issue can you included the output of

which root
which root.exe
echo $ROOTSYS
echo $LD_LIBRARY_PATH
echo $PATH
ldd `which root.exe`
ldd path_name_to_you_exec_or_library
ls -l path_name_to_you_exec_or_library

M.Bona · April 10, 2018, 7:59am

I see, these are exactly the same messages I get when I run valgrind on my macro.

which root
> /usr/bin/root

which root.exe
> /usr/bin/root.exe

echo `root-config --etcdir`
> /etc/root

ldd `which root.exe`
	linux-vdso.so.1 (0x00007ffdd2925000)
	libRint.so => /usr/lib/root/libRint.so (0x00007f81af7be000)
	libCore.so => /usr/lib/root/libCore.so (0x00007f81af183000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f81aedfc000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f81aebe5000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f81ae82e000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f81afbe9000)
	libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f81ae5bb000)
	liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f81ae395000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f81ae17e000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f81adf7a000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007f81adc2e000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f81ada10000)

ldd /home/matteo/mu_beam\ bumps/test_analisi.C
>  ldd: warning: you do not have execution permission for `/home/matteo/mu_beam bumps/test_analisi.C'
	not a dynamic executable

ls -l /home/matteo/mu_beam\ bumps/test_analisi.C
> -rw-r--r-- 1 matteo matteo 17201 10 apr 09.42 '/home/matteo/mu_beam bumps/test_analisi.C'

sbinet · April 10, 2018, 8:14am

Philippe was asking for the.so resulting from the compilation of your macro, I think.

so instead of:

$> ldd /home/matteo/mu_beam\ bumps/test_analisi.C

which is non-sensical, you should run:

$> ldd /home/matteo/mu_beam\ bumps/test_analisi.C.so

(or whatever the name one gets is when compiling a ROOT macro.)

M.Bona · April 10, 2018, 8:40am

I didn’t understand: when I write a ROOT macro I do not compile it, so I do not have an executable/library to run ldd. What am I doing wrong?

sbinet · April 10, 2018, 8:45am

you can compile a macro from the ROOT prompt:

$> cat foo.C
#include <iostream>

void foo() {
	std::cout << "hello from foo\n";
}

$> root -b
root [0] .x foo.C+
Info in <TUnixSystem::ACLiC>: creating shared library /home/binet/tmp/root-data/./foo_C.so
hello from foo
root [1] foo()
hello from foo
root [2] .q

$> ldd ./foo_C.so 
	linux-vdso.so.1 (0x00007fff64b7d000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007fe494461000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fe49425d000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007fe493ea6000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fe493c8f000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fe493908000)
	libRint.so => /usr/lib/root/libRint.so (0x00007fe4936e0000)
	libCore.so => /usr/lib/root/libCore.so (0x00007fe4930a5000)
	libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007fe492e33000)
	liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007fe492c0d000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007fe4929f6000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fe4927d8000)
	libnss_files.so.2 => /usr/lib/libnss_files.so.2 (0x00007fe4925c6000)
	libnss_mymachines.so.2 => /usr/lib/libnss_mymachines.so.2 (0x00007fe492386000)
	libnss_myhostname.so.2 => /usr/lib/libnss_myhostname.so.2 (0x00007fe492174000)
	libRIO.so => /usr/lib/root/libRIO.so (0x00007fe491c77000)
	libThread.so => /usr/lib/root/libThread.so (0x00007fe491a2a000)
	libCling.so => /usr/lib/root/libCling.so (0x00007fe48e9c5000)
	libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007fe48e758000)
	/usr/lib64/ld-linux-x86-64.so.2 (0x00007fe4949b0000)
	libMathCore.so => /usr/lib/root/libMathCore.so (0x00007fe48e35f000)
	libImt.so => /usr/lib/root/libImt.so (0x00007fe48e151000)
	libtbb.so.2 => /usr/lib/libtbb.so.2 (0x00007fe48df14000)
	librt.so.1 => /usr/lib/librt.so.1 (0x00007fe48dd0c000)

pcanal · April 10, 2018, 4:42pm

In addition what is the content of your macro? Does it used any of your libraries or just ROOT libraries?

M.Bona · April 12, 2018, 7:43am

In my macro I open a TFile and get the TTree in it, then I read the tree event by event and perform different operations with TBranches, most of which are std::vector<double> type. I am using only ROOT libraries and the c++ standard library. I will compile my macro, as suggested by sbinet, and send the output as soon as possible.

Thanks!
Matteo

sbinet · April 12, 2018, 8:00am

if you were to post a small reproducer (data+macro) here, we could help you with more concrete suggestions