Assert() in ROOT6

ROOT
1

I have some assert statements in code that I am using. However, when using root 6.04/02, these assert statements have no effect. It seems to happen when the assert statements is inside function compiled with ACLiC. This can be reproduced as follows.

In “func.C”

void func() {
  assert(false);
}

In the interpreter

username@hostname ~ $ root -n
   ------------------------------------------------------------
  | Welcome to ROOT 6.04/02                http://root.cern.ch |
  |                               (c) 1995-2014, The ROOT Team |
  | Built for linuxx8664gcc                                    |
  | From tag v6-04-02, 14 July 2015                            |
  | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q' |
   ------------------------------------------------------------

root [0] .L func.C+
Info in <TUnixSystem::ACLiC>: creating shared library /user/username/./func_C.so
root [1] func()
root [2]
2

Yes, it seems ok when not using AClic:

root [0] .x func.C
Assertion failed: (false), function func, file /Users/couet/roottest/func.C, line 2.
$
3

I agree, it does seem to be an issue with ACLiC itself. If I run func() in interpreted mode, or if I compile func() using g++, the assertion is handled correctly. What makes ACLiC different from either of these methods, such that the assertion is ignored?

4

I have no idea but I asked some expert to look at it.
Note that I also tried with ROOT 5 and it is the same behavior.
That’s not specify to ROOT 6 as the title of the post would suggest.

5

Interesting. I had tested it with root 5.34/36, and there the assert is being handled correctly, with output as shown below. This is why I had assumed that it was due to some change between root5 and root6.

username@hostname ~ $ \root -b -n
  *******************************************
  *                                         *
  *        W E L C O M E  to  R O O T       *
  *                                         *
  *   Version   5.34/36      5 April 2016   *
  *                                         *
  *  You are welcome to visit our Web site  *
  *          http://root.cern.ch            *
  *                                         *
  *******************************************

ROOT 5.34/36 (v5-34-36@v5-34-36, Apr 05 2016, 10:25:45 on linuxx8664gcc)

CINT/ROOT C/C++ Interpreter version 5.18.00, July 2, 2010
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
root [0] .L func.C+
Info in <TUnixSystem::ACLiC>: creating shared library /user/username/./func_C.so
root [1] func()
root.exe: /user/username/./func.C:2: void func(): Assertion `false' failed.
username@hostname ~ $
6

For me root 5 gives:

$ root
  *******************************************
  *                                         *
  *        W E L C O M E  to  R O O T       *
  *                                         *
  *   Version   5.34/37      6 April 2016   *
  *                                         *
  *  You are welcome to visit our Web site  *
  *          http://root.cern.ch            *
  *                                         *
  *******************************************

ROOT 5.34/37 (heads/v5-34-00-patches@v5-34-36-1-g4008982, Jul 13 2016, 09:26:00 on macosx64)

CINT/ROOT C/C++ Interpreter version 5.18.00, July 2, 2010
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
root [0] .L func.C+
root [1] func()
root [2]
7

Hi,

assert are no-op when compiled in ‘release’ mode (i.e. unless NDEBUG is false and/or -g is used).

ACLiC default to using ROOT’s build option and thus you are likely compiling the library in optimized/NDEBUG mode.

See the result of
.L func.C++g
The second + force the recompilation of the library and the ‘g’ request debug mode.

Cheers,
Philippe.

8

This problem seems to exist still:

root [0] assert(0==1)
root [1] gROOT->GetVersion()
(const char *) “6.24/01”

9

Hi @quantiser ,
in C++ asserts are a debug feature, they can be no-op when code is compiled in release mode. It looks like that’s what the interpreter does.

For an assert equivalent that is always executed, you can use R__ASSERT.

Cheers,
Enrico

1 Like
10

Thanks!
In the end, I realized I can always define my own asert as a preprocessor directive.