So in root 6.10, entering a undeclared identifier reports an error and recovers, as I’d expect:
Error: Symbol qqq is not defined in current scope (tmpfile):1:
*** Interpreter error recovered ***
Since at least 6.11.02, root terminates with:
input_line_17:2:3: error: use of undeclared identifier ‘qqq’
(qqq)
^
terminate called after throwing an instance of ‘cling::CompilationException’
what(): Error evaluating expression (qqq)
So, basically a typo can crash your session. Couldn’t find a bug report in minimal searching. Is this the new normal?
Thanks. I see you’re using /opt/rh/devtoolset-4/root/usr/bin/c++. The devtoolset stdlib is not supported; they inject symbols into the binary to patch missing ones from the system stdlibc++. ROOT’s interpreter cling doesn’t support that (yet) - which is very likely the cause for what you’re seeing.
Please move to CentOS7, or use a “proper” GCC (I believe EPEL has one?)
I managed to track it down to a strange combination of things. Here is the minimum setup I have found to reproduce it:
.rootrc should contain:
Rint.Logon: $(HOME)/.rootlogon.C
.rootlogon.C should contain:
{
gROOT->LoadMacro(“/tmp/foo.C”);
}
and /tmp/foo.C can contain any named function (which can actually be empty):
void foo(){cout << “hi” << endl;}
With this config, an undeclared identifier causes a terminate. If the either of the lines in the first 2 files are commented out, then no terminate. If foo.C is replaced by an unnamed macro (e.g., just {cout << “hi” << endl;}, then no terminate.
No terminate happens with v5.34.36, v6.10.02, v6.10.08
Terminate always happens with v6.11.02 and v6.12.04
I cannot reproduce it, even with the exact same binary you downloaded, using your setup:
$ wget https://root.cern.ch/download/root_v6.12.04.Linux-centos7-x86_64-gcc4.8.tar.gz
$ tar xzf root_v6.12.04.Linux-centos7-x86_64-gcc4.8.tar.gz
$ . root/bin/thisroot.sh
$ root -l -b
root [0] foo()
hi
root [1] aaa
input_line_14:2:3: error: use of undeclared identifier 'aaa'
(aaa)
^
Error in <HandleInterpreterException>: Error evaluating expression (aaa).
Execution of your code was aborted.
root [2] .q
-bash-4.2$ root -l -b
root [0] aaa
input_line_13:2:3: error: use of undeclared identifier 'aaa'
(aaa)
^
Error in <HandleInterpreterException>: Error evaluating expression (aaa).
Execution of your code was aborted.
root [1] .q
But I have a suspicion. @pcanal can we assert whether we have the JIT memory layout vs landing pad issue? Could we maybe add a function that people can call that checks that?
can we assert whether we have the JIT memory layout vs landing pad issue?
Unfortunately, I have not found a way. The ‘bad’ behavior was/is extremely dependent on memory use, fragmentation and allocation ordering … and usually it failed when the allocation did not land where you would expect them … i.e. forcing the system in the wrong state is ‘hard’ to do (and even things like moving the physical location of the compiler could tilt the problem away …).
That said, there is a few thing that can be done to debug.
a) run the failing case under valgrind to see if it is an obvious ‘other’ problem
b) look at the stack trace when the exception is thrown
c) assembly step through after the exception is thrown …
c) is ‘longish’ but basically you type ‘stepi’ many times (or if you are using gdb, just press enter after the initial stepi … If you never end in the catch clause but end in the terminate then you have a hint that it is the problem Axel is referring to.