Created attachment 1205143 [details]
Traceback generated by root

Description of problem:

All use of TGeo (and other classes) causes a segmentation fault

Version-Release number of selected component (if applicable):

root-6.06.08-1.fc24.x86_64
root-geom-6.06.08-1.fc24.x86_64


How reproducible:

Always

Steps to Reproduce:
1. Start root
2. Type "TGeoManager m;"

Actual results:

error: expected unqualified-id
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
error: source file is not valid UTF-8
fatal error: too many errors emitted, stopping now [-ferror-limit=]

 *** Break *** segmentation violation



===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================

followed by a long traceback (see attachment)

Expected results:

An instance of TGeoManager should be created.

Additional info:

The problem is not specific to TGeoManager or even to root-geom. It occurs with many different classes and appears to be at the point, where the class is loaded. In fact, it is enough to do TGeoManager m( and then hit TAB. Unfortunately, it seems to be very hard to figure out exactly what it is parsing when this happens.

Playing around in gdb seems to indicate that the first message "error: expected unqualified-id" occurs at interpreter/llvm/src/tools/clang/lib/Parse/ParseDecl.cpp:5073
and it looks like it is parsing gNonInterpreterClassDef, which is defined in TCling.cxx:263.

The second error is at interpreter/llvm/src/tools/clang/lib/Lex/Lexer.cpp:3622 and it looks like it is parsing /usr/include/c++/6.2.1/x86_64-redhat-linux/bits/c++config.h as Lexer::BufferStart points to the string "#ifndef _CPP_CPPCONFIG_WRAPPER\n#define _CPP_CPPCONFIG_WRAPPER 1\n#include <bits/wordsize.h>\n#if __WORDSIZE == 32\n// Predefined symbols and macros -*- C++ -*-\n\n// Copyright (C) 1997-2016 Free Software F"... which seems to come from this file.

Indeed, if I start root, then
#include "/usr/include/c++/6.2.1/x86_64-redhat-linux/bits/c++config.h"
TGeoManager m;
it doesn't crash, doesn't give error messages and behaves as expected.

Strangely, that file (from libstdc++-devel-6.2.1-2.fc24.x86_64) seems OK. However, I happen to have an old VirtualBox image lying around (from testing prior to upgrading), with a version of Fedora 24 prior to the root-6.06.08 update, which has:
libstdc++-devel-6.1.1-3.fc24.x86_64
root-6.06.06-4.fc24.x86_64
root-geom-6.06.06-4.fc24.x86_64
and on that, there is no problem. In that version of libstdc++-devel there is a crucial difference in c++config.h. In two places, the line:
# define _GLIBCXX_ASSERTIONS
was changed to
# define _GLIBCXX_ASSERTIONS 1

If I revert that change to c++config.h on the fully updated system, the problem is worked around.

Also if I now run sudo dnf update libstdc++-devel -y on that old image, keeping root at 6.06.06, the problem occurs with root-6.06.06 as well. Again, modifying c++config.h works around the problem.

I can't figure out which bit of code, root is barfing on, that is added when _GLIBCXX_ASSERTIONS is set to 1 rather than just simply being defined.

Also, I don't understand, why I can't trigger this problem on Fedora 25 alpha, even though the c++config.h files and root version are identical.

So to summarize:
- the problem is in root-6.06.06 and root-6.06.08
- it is triggered by #define _GLIBCXX_ASSERTIONS 1 in c++config.h
- there _might_ be a coding error in libstdc++-devel which triggers the bug
- there is _definitely_ a bug in root, which causes it to segfault rather than complain about the code