Segmentation Fault When Reading Ntuple in a macro

Newbie
1

Dear Experts:
I try to read in a ntuple object in this macro but get a segmentation fault when execute run -x test.mac. There is no Error when i type in the command lines in root session. How could this happen?

{
    TFile f("Neutron_001eV_LiF_1mm.root");
    TNtuple* ntuple = (TNtuple*)f.Get("SimResults");
    ntuple->GetEntry(0);
    float* row = ntuple->GetArgs();
    if(row == nullptr) std::cout << "it is null" << std::endl;
    else    std::cout << row[0] << row[1] << row[2]<<std::endl;
}

The Error Message is below:

Processing test.C...

 *** Break *** segmentation violation



===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
#0  0x00007fedbe177457 in __GI___waitpid (pid=1132, stat_loc=stat_loc
entry=0x7ffe03a1fc28, options=options
entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1  0x00007fedbe0e2177 in do_system (line=<optimized out>) at ../sysdeps/posix/system.c:149
#2  0x00007fedbe77b813 in TUnixSystem::StackTrace() () from /usr/local/root6.22_install/lib/libCore.so
#3  0x00007fedbe77e305 in TUnixSystem::DispatchSignals(ESignals) () from /usr/local/root6.22_install/lib/libCore.so
#4  <signal handler called>
#5  0x00007fedbeea222a in ?? ()
#6  0x00007fedbeea2200 in ?? ()
#7  0xf5c8a06fe8ec0d00 in ?? ()
#8  0x00007ffe03a226f0 in ?? ()
#9  0x00005619f809ea90 in ?? ()
#10 0x00005619f809ea90 in ?? ()
#11 0x00007fedb96737e8 in cling::MultiplexInterpreterCallbacks::EnteringUserCode() () from /usr/local/root6.22_install/lib/libCling.so
#12 0x00007ffe03a232b0 in ?? ()
#13 0x00007fedbeea2200 in ?? ()
#14 0x00007fedb96e66c0 in cling::IncrementalExecutor::executeWrapper(llvm::StringRef, cling::Value*) const () from /usr/local/root6.22_install/lib/libCling.so
#15 0x00007fedb96753e6 in cling::Interpreter::RunFunction(clang::FunctionDecl const*, cling::Value*) () from /usr/local/root6.22_install/lib/libCling.so
#16 0x00007fedb9676559 in cling::Interpreter::EvaluateInternal(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, cling::CompilationOptions, cling::Value*, cling::Transaction**, unsigned long) () from /usr/local/root6.22_install/lib/libCling.so
#17 0x00007fedb96767da in cling::Interpreter::process(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, cling::Value*, cling::Transaction**, bool) () from /usr/local/root6.22_install/lib/libCling.so
#18 0x00007fedb9737e0f in cling::MetaProcessor::readInputFromFile(llvm::StringRef, cling::Value*, unsigned long, bool) () from /usr/local/root6.22_install/lib/libCling.so
#19 0x00007fedb95f0c84 in TCling::ProcessLine(char const*, TInterpreter::EErrorCode*) () from /usr/local/root6.22_install/lib/libCling.so
#20 0x00007fedb95f1762 in TCling::ProcessLineSynch(char const*, TInterpreter::EErrorCode*) () from /usr/local/root6.22_install/lib/libCling.so
#21 0x00007fedbe61f438 in TApplication::ExecuteFile(char const*, int*, bool) () from /usr/local/root6.22_install/lib/libCore.so
#22 0x00007fedbe61ec60 in TApplication::ProcessLine(char const*, bool, int*) () from /usr/local/root6.22_install/lib/libCore.so
#23 0x00007fedbebf6fd2 in TRint::ProcessLineNr(char const*, char const*, int*) () from /usr/local/root6.22_install/lib/libRint.so
#24 0x00007fedbebf88c9 in TRint::Run(bool) () from /usr/local/root6.22_install/lib/libRint.so
#25 0x00005619f5e06a0c in main ()
===========================================================


The lines below might hint at the cause of the crash.
You may get help by asking at the ROOT forum http://root.cern.ch/forum
Only if you are really convinced it is a bug in ROOT then please submit a
report at http://root.cern.ch/bugs Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#5  0x00007fedbeea222a in ?? ()
#6  0x00007fedbeea2200 in ?? ()
#7  0xf5c8a06fe8ec0d00 in ?? ()
#8  0x00007ffe03a226f0 in ?? ()
#9  0x00005619f809ea90 in ?? ()
#10 0x00005619f809ea90 in ?? ()
#11 0x00007fedb96737e8 in cling::MultiplexInterpreterCallbacks::EnteringUserCode() () from /usr/local/root6.22_install/lib/libCling.so
#12 0x00007ffe03a232b0 in ?? ()
#13 0x00007fedbeea2200 in ?? ()
#14 0x00007fedb96e66c0 in cling::IncrementalExecutor::executeWrapper(llvm::StringRef, cling::Value*) const () from /usr/local/root6.22_install/lib/libCling.so
#15 0x00007fedb96753e6 in cling::Interpreter::RunFunction(clang::FunctionDecl const*, cling::Value*) () from /usr/local/root6.22_install/lib/libCling.so
#16 0x00007fedb9676559 in cling::Interpreter::EvaluateInternal(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, cling::CompilationOptions, cling::Value*, cling::Transaction**, unsigned long) () from /usr/local/root6.22_install/lib/libCling.so
#17 0x00007fedb96767da in cling::Interpreter::process(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, cling::Value*, cling::Transaction**, bool) () from /usr/local/root6.22_install/lib/libCling.so
#18 0x00007fedb9737e0f in cling::MetaProcessor::readInputFromFile(llvm::StringRef, cling::Value*, unsigned long, bool) () from /usr/local/root6.22_install/lib/libCling.so

_ROOT Version: 6-22-02
_Platform: Ubuntu 18.04
_Compiler: gcc 10.2.0
___[HotBeam_Neutron_LiF.root|attachment]

The root file is too big , so i upload this smaller one, they have the same structure.
(upload://dkVnussj8Al5k4QtOfXjYQga9pl.root) (230.9 KB)

2

Hi,
please check out this guide on posting code to make your post more readable.

A segmentation fault with a stacktrace that involves code under EnteringUserCode most probably means that you have a bug in your code, most likely you are accessing a null pointer or non-existent array elements.

My advice would be to check that ntuple is not a nullptr, that row is not a nullptr, and that row has really 3 elements.

Cheers,
Enrico

3

eguiraud

Thanks for your reply, I have reedited the post.
‘row’ is not nullptr. The weird thing is that, I have typed the command lines in root session and got no error. But when i wrote them in a macro the segmentation fault occurs.

4

I am pretty that the code should have no bug.

5

Hi,

what does this mean? Shouldn’t it be the other way around?

6

if row is a nullptr print out something otherwise read the ntuple row.

7

the message doesn’t matter :sweat_smile:

8

A “segfault”, or “segmentation fault” (or “segmentation violation”) means that your program tried to access an invalid memory location.

I don’t see anything that ROOT might be doing wrong there. If ntuple and row are not nullptrs, then this leaves the access to array elements – row probably does not have 3 elements.

The fact that you don’t get a crash sometimes is typical of invalid memory access problems: what addresses are invalid depends on how memory has been allocated by the program. row[2] might be invalid memory or might be the content of other adjacent variables, allocated by the program right there at that address (in which case you would read garbage values but not get a segfault).

9

what does ntuple->GetNvar() return?

10

GetNvar() got segmentation fault too.
Yes, seems that the data i got in root session was not true.
Perhaps the data stored in the root file is not correct? But I still can draw the histograms of the 5 columns.
Thanks for your advice, maybe i should use TFile directly in the Geant4 code rather than use g4analysis manager.

11

If you can share the ROOT file I might be able to take a look (but no promises, I’m afraid these weeks before Christmas are really busy!)

12

Neutron_001eV_LiF_1mm.zip (713.5 KB)
That would be great!!! Thanks very much, eguiraud.
I think the histogram is correct, so maybe I misused the GetArgs() method to achieve columns?

13

Ah, "SimResults" is not a TNtuple, is a TTree, that’s the problem.

(TNtuple*)f.Get("SimResults") unconditionally casts the pointer returned by Get to TNtuple*, even if the content of the file is not of that type. You should use the safer TNtuple *ntuple = nullptr; f.GetObject("SimResults", ntuple), which would result in a nullptr in this case, or with newer ROOT versions also just auto ntuple = f.Get<TNtuple>("SimResults") (which would also return a nullptr since the object is not a TNtuple).

Cheers,
Enrico

14

Yeah, That the problem. Thanks very lot, eguiraud.