Root quits when including header file

vaubee · December 17, 2024, 7:07pm

ROOT Version: 6.30.06
Platform: Ubuntu 22.04
Compiler: g++ 11.4.0/clang++ 14.0.0

As described in another issue, when I try to include a custom class in an example script, root quits w/o error message when including the header file:

I tried replacing the myGraph class in the example with the more complicated one that I have, but whenever I add the line
#include "TCalibrationGraph.h"
to include the custom classes, root just exits without any error message or anything else. This happens if I do that in the example script, or even if I just type that line in cint. I tried using .L Test.C+ to see if that shows me more, and I needed to add some more include statements to get that to “work”, but even then, root quits without error message after outputting
Info in <TUnixSystem::ACLiC>: creating shared library /path/./Test_C.so

pcanal · December 17, 2024, 7:37pm

Can you try

valgrind --suppressions=$ROOTSYS/etc/valgrind-root.supp --log-file=val.01.log root.exe -b -l -q -e '.L Test.C++'

and upload the file val.01.log?

vaubee · December 17, 2024, 8:51pm

This is the content of val.01.log:

==3298635== Memcheck, a memory error detector
==3298635== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3298635== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==3298635== Command: root.exe -b -l -q -e .L\ Test.C++
==3298635== Parent PID: 3719246
==3298635== 
==3298635== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==3298635== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==3298635== Can't extend stack to 0x1ffe8010b8 during signal delivery for thread 1:
==3298635==   no stack segment
==3298635== 
==3298635== Process terminating with default action of signal 11 (SIGSEGV)
==3298635==  Access not within mapped region at address 0x1FFE8010B8
==3298635== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==3298635==    at 0x4FE107D: realpath_stk (canonicalize.c:312)
==3298635==  If you believe this happened as a result of a stack
==3298635==  overflow in your program's main thread (unlikely but
==3298635==  possible), you can try to increase the size of the
==3298635==  main thread stack using the --main-stacksize= flag.
==3298635==  The main thread stack size used in this run was 8388608.
==3298635== 
==3298635== HEAP SUMMARY:
==3298635==     in use at exit: 80,715,121 bytes in 229,448 blocks
==3298635==   total heap usage: 2,810,958 allocs, 2,581,510 frees, 872,719,919 bytes allocated
==3298635== 
==3298635== LEAK SUMMARY:
==3298635==    definitely lost: 8,064 bytes in 69 blocks
==3298635==    indirectly lost: 0 bytes in 0 blocks
==3298635==      possibly lost: 13,848 bytes in 52 blocks
==3298635==    still reachable: 80,479,900 bytes in 227,134 blocks
==3298635==                       of which reachable via heuristic:
==3298635==                         newarray           : 8,536 bytes in 17 blocks
==3298635==                         multipleinheritance: 9,992 bytes in 12 blocks
==3298635==         suppressed: 213,309 bytes in 2,193 blocks
==3298635== Rerun with --leak-check=full to see details of leaked memory
==3298635== 
==3298635== For lists of detected and suppressed errors, rerun with: -s
==3298635== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 812 from 78)

pcanal · December 17, 2024, 9:19pm

It appears that this is an infinite recursions … maybe.
try

gdb --args root.exe -b -l -q -e '.L Test.C++'
> run
... crash
> bt

ferhue · December 18, 2024, 5:47pm

did you put an ifdef header-guard in all of your headers ? Maybe there is a typo in one of the header guards, or a repeated one?

vaubee · December 18, 2024, 6:19pm

Running gdb gives a very long backtrace which I can’t post here in full, but it seems to just repeat, this shows two of the repeating blocks:

#5  0x00007ffff177b95e in TCling::Load(char const*, bool) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#6  0x00007ffff7cf5e72 in TSystem::Load(char const*, char const*, bool) () from /opt/cern/root/root_v6.30.06/lib/libCore.so
#7  0x00007ffff1779a5a in TCling::LazyFunctionCreatorAutoload(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#8  0x00007ffff1779c50 in TCling::LibraryLoadingFailed(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, bool) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#9  0x00007ffff186fefd in cling::MultiplexInterpreterCallbacks::LibraryLoadingFailed(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, bool) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#10 0x00007ffff184e466 in cling::DynamicLibraryManager::loadLibrary(llvm::StringRef, bool, bool) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#11 0x00007ffff1869adb in cling::Interpreter::loadFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, cling::Transaction**) ()
   from /opt/cern/root/root_v6.30.06/lib/libCling.so
#12 0x00007ffff1946943 in cling::MetaSema::actOnLCommand(llvm::StringRef, cling::Transaction**) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#13 0x00007ffff1956070 in cling::MetaParser::isCommand(cling::MetaSema::ActionResult&, cling::Value*) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#14 0x00007ffff193f720 in cling::MetaProcessor::process(llvm::StringRef, cling::Interpreter::CompilationResult&, cling::Value*, bool) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#15 0x00007ffff176d84c in HandleInterpreterException(cling::MetaProcessor*, char const*, cling::Interpreter::CompilationResult&, cling::Value*) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#16 0x00007ffff177ba05 in TCling::Load(char const*, bool) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#17 0x00007ffff7cf5e72 in TSystem::Load(char const*, char const*, bool) () from /opt/cern/root/root_v6.30.06/lib/libCore.so
#18 0x00007ffff1779a5a in TCling::LazyFunctionCreatorAutoload(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#19 0x00007ffff1779c50 in TCling::LibraryLoadingFailed(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, bool) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#20 0x00007ffff186fefd in cling::MultiplexInterpreterCallbacks::LibraryLoadingFailed(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, bool) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#21 0x00007ffff184e466 in cling::DynamicLibraryManager::loadLibrary(llvm::StringRef, bool, bool) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#22 0x00007ffff1869adb in cling::Interpreter::loadFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, cling::Transaction**) ()
   from /opt/cern/root/root_v6.30.06/lib/libCling.so
#23 0x00007ffff1946943 in cling::MetaSema::actOnLCommand(llvm::StringRef, cling::Transaction**) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#24 0x00007ffff1956070 in cling::MetaParser::isCommand(cling::MetaSema::ActionResult&, cling::Value*) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#25 0x00007ffff193f720 in cling::MetaProcessor::process(llvm::StringRef, cling::Interpreter::CompilationResult&, cling::Value*, bool) () from /opt/cern/root/root_v6.30.06/lib/libCling.so
#26 0x00007ffff176d84c in HandleInterpreterException(cling::MetaProcessor*, char const*, cling::Interpreter::CompilationResult&, cling::Value*) () from /opt/cern/root/root_v6.30.06/lib/libCling.so

vaubee · December 18, 2024, 6:35pm

Yes, header guards are in.

pcanal · December 18, 2024, 7:34pm

This confirms the infinite recursions. Next to debug the problem further there is two different options:

Rebuild ROOT in debug mode (cmake ... -DCMAKE_BUILD_TYPE=Debug ... and run it again.
Reduce the content of the header the files (remove/hides) little by little (or using some sort of bisection of the content) until you find the part that triggers the problem.

ferhue · December 19, 2024, 8:03am

Could you share the full example including the header?

vaubee · December 19, 2024, 3:31pm

I’ve attached the script plus the header and source file for the custom class. Most of it is commented out right now as I’m trying to get it into a state where it works.

Test.C (7.6 KB)
TCalibrationGraph.h (9.4 KB)
TCalibrationGraph.cxx (34.9 KB)

vaubee · December 19, 2024, 4:17pm

I solved the issue. For this test I had created the Test.C script in a subdirectory of the project I’m working on, and copied the header and source files of the custom class into that subdirectory. When I renamed the class (and the files) from TCalibrationGraph to myGraph, it suddenly worked. So I guess root somehow got confused because the class also existed outside the directory I was using for these tests?

Though not everything is working, for some reason the created shared object file Test_C.so does not contain the definition of the custom classes constructor, so I will have to figure out how to do that correctly.

ferhue · December 19, 2024, 4:34pm

I tried with these three files, and when I run it, it compiles just fine, it never hangs in an infinite loop. So can’t really help much here.

vaubee · December 19, 2024, 4:53pm

Yes, it works for you because you do not have another copy of the files. Thanks for checking though, @ferhue!

ferhue · December 19, 2024, 5:07pm

Yep, I was interested in reproducing your recursive error even if it’s a weird case, so that it can be fixed in upstream ROOT to prevent this recursive situation. I tried copying the same files into a subdirectory and running from there, but still get a normal behaviour. If you find a recipe of subfolder structure that allows me to reproduce and check, let me know
F.

system · January 2, 2025, 5:08pm

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.