Scope issue with Cling?

ROOT
1

Please read tips for efficient and successful posting and posting code

Hi,

I wonder whether there is a solution for the following Cling scope issue that I encountered.

ncfs>root -b -q -e ‘gROOT->LoadMacro(“NcAstrolab2.cxx+”);’ test1.cc >test1.log

*** Break *** segmentation violation
Generating stack trace…
0x00007f09ac27e764 in TObjArray::~TObjArray() + 0x24 from /home/nickve/software/root_v6.24.08/lib/libCore.so.6.24
0x00007f09843425d7 in NcAstrolab2::~NcAstrolab2() + 0x247 from /mnt/c/nick/test/NcGRB/alerts/NcAstrolab2_cxx.so
0x00007f09a61e8324 in from /home/nickve/software/root_v6.24.08/lib/libCling.so
0x00007f09a6163e49 in from /home/nickve/software/root_v6.24.08/lib/libCling.so
0x00007f09a606e45d in TCling::ResetGlobals() + 0x3d from /home/nickve/software/root_v6.24.08/lib/libCling.so
0x00007f09ac1b0bdd in TROOT::EndOfProcessCleanups() + 0x2d from /home/nickve/software/root_v6.24.08/lib/libCore.so.6.24
0x00007f09ac320e0f in TUnixSystem::Exit(int, bool) at TUnixSystem.cxx:? from /home/nickve/software/root_v6.24.08/lib/libCore.so.6.24
0x00007f09ac1becfb in TApplication::Terminate(int) + 0x4b from /home/nickve/software/root_v6.24.08/lib/libCore.so.6.24
0x00007f09ac7e1a55 in TRint::Run(bool) + 0x245 from /home/nickve/software/root_v6.24.08/lib/libRint.so.6.24
0x00007f09ace00a6c in main + 0x4c from /home/nickve/software/root_v6.24.08/bin/root.exe
0x00007f09ab691b97 in __libc_start_main + 0xe7 from /lib/x86_64-linux-gnu/libc.so.6
0x00007f09ace00aca in _start + 0x2a from /home/nickve/software/root_v6.24.08/bin/root.exe
ncfs>

I have the ROOT macro test1.cc and the source code NcAstrolab2.h and NcAstrolab2.cxx attached. I could trace the error back to the fact that at the end of the job, the NcAstrolab dtor is called first and then the dtor of the TObjArray fBurstHistos is called. This fBurstHistos holds pointers to various histograms and owns them, so that all histograms would be properly deleted when the job has finished. However, it seems that Cling already deleted the histograms when the NcAstrolab instance (called “lab” in the macro test1.cc) went out of scope after the job ended. Note that the job was processed correctly and that all histograms were correctly produced, as can be seen from the output file test1.txt (which actually is the produced test1.log, but .log is not an allowed extension for uploading here).

To prove that it indeed is a scope issue, I also run the attached ROOT macro test2.cc, which runs properly without a segmentation violation.

Is it necessary to use always the “new constructor” for objects in a ROOT macro, or is there also another way to make test1.cc run without a crash ?

test2.cc (2.7 KB)

test1.cc (2.6 KB)

NcAstrolab2.h (36.0 KB)

NcAstrolab2.cxx (645.2 KB)

test1.txt (11.6 KB)

Please fill also the fields below. Note that root -b -q will tell you this info, and starting from 6.28/06 upwards, you can call .forum bug from the ROOT prompt to pre-populate a topic.

ROOT Version: 6.24/08 (took binaries for Ubuntu)
Platform: Ubuntu under a Windows10 powershell
Compiler: ACliC (and the other shared libs were created with gcc)

2

I guess @pcanal or @devajith can help.

3

Hi @Nick_van_Eijndhoven, from your logs you seem to be running 6.24, which is now quite old and was released a couple years ago.

Would you be able to provide a more minimal reproducer (that does not require all the ncfc headers) so that I can try to reproduce the issue on my end (with a more recent version of ROOT) and see if the issue still exists?

Cheers,
Dev

4

Hi Dev,
Thanks for looking into this.
I will try to make a pure ROOT based macro to reproduce the problem.
However, on my laptop I am currently stuck with this ROOT 6.24/08 release
since I took the binaries for my Ubuntu 18.04 (bionic) platform that runs
under my Windows10 powershell.
On our Alma9 cluster I can use cvmfs releases and there I ran the same test with

5

Hi Dev,

Thanks for looking into this.

I will try to make a pure ROOT based macro to reproduce the problem.

However, on my laptop I am currently stuck with this ROOT 6.24/08 release

since I took the binaries for my Ubuntu 18.04 (bionic) platform that runs

under my Windows10 powershell.

On our Alma9 cluster I can use cvmfs releases and there I ran the same test with

| Welcome to ROOT 6.34.02 https://root.cern |
| (c) 1995-2024, The ROOT Team; conception: R. Brun, F. Rademakers |
| Built for linuxx8664gcc on Jan 31 2025, 23:21:21 |
| From tags/6-34-02@6-34-02 |
| With g++ (GCC) 11.3.0 |

Try ‘.help’/‘.?’, ‘.demo’, ‘.license’, ‘.credits’, ‘.quit’/‘.q’

and on that system I did NOT get the segmentation violation.

But, I have seen before that the order in which objects are deleted

upon ending a ROOT macro, may depend on how things are located in memory.

So, maybe on the Alma9 I am just lucky this time.

Or do you know of something that was changed in ACLiC or Cling between

ROOT 6.24/08 and 6.34/02 that might have resolved this issue ?

Anyhow, I will try to reproduce it with a bare ROOT based macro and

will let you know when I got something for you to test.

Just for completeness : I never got this problem when running with the ROOT 5.34 release, under which I have run many of these jobs both on my Ubuntu system and on our SL7 cluster.

Cheers,

Nick.

6

Try

valgrind --suppressions=$ROOTSYS/etc/valgrind-root.supp root.exe -b -q -e ‘gROOT->LoadMacro(“NcAstrolab2.cxx+”);’ test1.cc

to pin point the issue.

7

Hi Philippe, all,

I was just trying things out, and decided to change the unnamed ROOT macro into a named one. So for the file test1.cc (which gave the crash after finishing) I named the macro void test1() and guess what …. No crash anymore! So it seems that one has to use only named macros in order to prevent the out of scope c.q. delete problem I encountered.

8

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