Bug 1379639 - Segfault with TGeo (and others) triggered by c++config.h in libstdc++-devel
Summary: Segfault with TGeo (and others) triggered by c++config.h in libstdc++-devel
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: root
Version: 24
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Mattias Ellert
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-27 09:32 UTC by nvwarr
Modified: 2017-01-31 18:18 UTC (History)
2 users (show)

Fixed In Version: root-6.06.08-2.fc25 root-6.06.08-2.fc24 root-6.08.04-1.fc25 root-6.08.04-1.fc24 root-6.08.04-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-24 23:20:19 UTC


Attachments (Terms of Use)
Traceback generated by root (39.15 KB, text/plain)
2016-09-27 09:32 UTC, nvwarr
no flags Details
New traceback generated by root (40.68 KB, text/plain)
2017-01-11 07:23 UTC, nvwarr
no flags Details

Description nvwarr 2016-09-27 09:32:59 UTC
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

Comment 1 Fedora Update System 2016-09-30 20:24:12 UTC
root-6.06.08-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-fab057791f

Comment 2 Fedora Update System 2016-10-01 05:27:46 UTC
root-6.06.08-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-5ce365d3ca

Comment 3 nvwarr 2016-10-04 07:16:49 UTC
Thanks for the quick response. Yes. This fixes the bug. As far as I am concerned, it can be closed.

Comment 4 Fedora Update System 2016-10-09 02:46:26 UTC
root-6.06.08-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 5 Fedora Update System 2016-10-09 06:20:52 UTC
root-6.06.08-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 6 nvwarr 2017-01-10 08:40:55 UTC
After upgrading libstdc++ to libstdc++-6.3.1-1.fc24.x86_64, the problem is back.

This time, the workaround of changing the _GLIBCXX_ASSERTIONS lines in 
/usr/include/c++/6.3.1/x86_64-redhat-linux/bits/c++config.h doesn't help. However, including this file explicitly before creating an instance of TGeoManager does work around the problem.

This is with root-6.06.08-2.fc24.x86_64. Upgrading to root-6.08.02-1.fc24.x86_64 did not fix the problem. The problem is also present on Fedora 25 with root-6.08.02-1.fc25.x86_64.

Comment 7 nvwarr 2017-01-11 07:23:30 UTC
Created attachment 1239343 [details]
New traceback generated by root

Here's a new traceback after the problem reappeared. It looks like gNonInterpreterClassDef is getting munged. The method cling::Interpreter::parseForModule appears twice in the trace and the second time, the "\n" have been turned into "n".

Comment 8 nvwarr 2017-01-11 15:44:00 UTC
Adding the line

#include <c++/6.3.1/x86_64-redhat-linux/bits/c++config.h>

to the beginning of /usr/include/root/TGeoAtt.h seems to work around the problem, but obviously this will break if the libstdc++ version changes again.

Comment 9 Fedora Update System 2017-01-16 09:30:01 UTC
root-6.08.04-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d262290209

Comment 10 Fedora Update System 2017-01-16 09:30:13 UTC
root-6.08.04-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4aa1ced428

Comment 11 Fedora Update System 2017-01-16 09:30:21 UTC
root-6.08.04-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-31d707f653

Comment 12 Fedora Update System 2017-01-16 21:21:54 UTC
root-6.08.04-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-31d707f653

Comment 13 Fedora Update System 2017-01-16 22:22:56 UTC
root-6.08.04-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4aa1ced428

Comment 14 Fedora Update System 2017-01-16 22:23:36 UTC
root-6.08.04-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d262290209

Comment 15 nvwarr 2017-01-17 12:18:24 UTC
Yes, that fixes it. Thanks for another quick response.

Comment 16 Fedora Update System 2017-01-24 23:20:19 UTC
root-6.08.04-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 17 Fedora Update System 2017-01-25 00:21:18 UTC
root-6.08.04-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 18 Fedora Update System 2017-01-31 18:18:06 UTC
root-6.08.04-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.