Description of problem: If a class includes a static variable that inherits from the basic string class, it will not be properly initialized during global initialization at runtime, i.e. before 'main' starts. Version-Release number of selected component (if applicable): Reports in the OpenFOAM user community indicate that it happens at least with both GCC 7 and 11 from the respective 'devtoolset' package. How reproducible: Always. Steps to Reproduce: 1. Build OpenFOAM.org 9 or 10 with GCC from one of the devtoolset packages. 2. Copy the tutorial case 'heatTransfer/chtMultiRegionFoam/reverseBurner'. 3. Run: gdb blockMesh 4. Then: run bt 5. See actual results below... Actual results: It crashes with the following stack trace: #0 std::operator==<char> (__lhs="includeFunc", __rhs=<error reading variable: Cannot access memory at address 0xffffffffffffffe8>, __lhs="includeFunc", __rhs=<error reading variable: Cannot access memory at address 0xffffffffffffffe8>) at /opt/rh/devtoolset-11/root/usr/include/c++/11/bits/basic_string.h:3963 #1 Foam::entry::New (parentDict=..., is=...) at db/dictionary/entry/entryIO.C:167 Expected results: It should not crash, because with both a custom vanilla GCC build or on Ubuntu, it does not have this issue. Additional info: The reports at the OpenFOAM user community are as follows: - https://www.cfd-online.com/Forums/openfoam-installation/241354-openfoam-dev-centos-7-9-segmentation-fault-when-executing-any-application.html - https://bugs.openfoam.org/view.php?id=3887 - https://bugs.openfoam.org/view.php?id=3898
Sorry for not providing a minimal proof of failure on this report, but from what I can figure out, the flaw is in one of the patches being used on the build stack of the RPM specs for building GCC. If I use a custom build of GCC 11.3.0 with its default 'include' folder, everything works just fine. If I use that same GCC with the main 'include' folder for 11.2.1 from SCL, I get the same exact problem as with the GCC 11.2.1 that comes from SCL. So the problem seems to originate from the changes made in SCL's RPM specs.
I'm referring to this spec file for example: https://git.centos.org/rpms/gcc-toolset-11-gcc/blob/c8/f/SPECS/gcc.spec I'm still unable to find where the patches listed there are coming from, along as to why they are being applied, to try and isolate which one might be triggering this error. By having this information, it would be easier for me to try and give a better indication of what is breaking the desired workflow.
I assume the difference is because DTS gcc defaults to the old std::string ABI (which is not going to change). Does -D_GLIBCXX_USE_CXX11_ABI=1 make a difference?
According to this bug report https://bugzilla.redhat.com/show_bug.cgi?id=1546704 it is not possible to set D_GLIBCXX_USE_CXX11_ABI=1 with DTS gcc, the setting is ignored. Is there a workaround? However, I tried to set D_GLIBCXX_USE_CXX11_ABI=0 when using Ubuntu gcc and I was able to reproduce the segmentation fault, so it is quite probable that this is the cause.
(In reply to Marek Polacek from comment #3) > I assume the difference is because DTS gcc defaults to the old std::string > ABI (which is not going to change). Does -D_GLIBCXX_USE_CXX11_ABI=1 make a > difference? I've tested this and it doesn't work, as Timo Niemi mentioned in comment #4. It seems to be a very odd behavior that a previous fix/workaround leads to a copy constructor that is simply not working due to an ABI compatibility issue... although it is not working only during the initialization phase of the application/library. But then again, if this is already broken in the original code when "_GLIBCXX_USE_CXX11_ABI=0"... I guess the issue is on GCC's side instead, which in turn doesn't make much sense to turn this off when using C++14.
At least personally I would see no reason of using an old ABI when compiling a C++ project requiring >= C++11 given the fact that the old ABI is not standard compliant. It can only work by chance if the code base doesn't happen to rely on newer features. But I guess the idea is that DTS compilers can be used to compile code which can then run on a system which has old libraries and this can work in some cases. Is there a possibility to somehow skip this behavior, or are the only choices either to modify source code or use other compilers than DTS gcc?
(Formal change: I'm updating a couple of attributes to place this ticket into a more suitable pool.)
(In reply to Timo Niemi from comment #4) > According to this bug report > https://bugzilla.redhat.com/show_bug.cgi?id=1546704 it is not possible to > set D_GLIBCXX_USE_CXX11_ABI=1 with DTS gcc, the setting is ignored. Is there > a workaround? I don't think so. The new ABI is unsupportable on RHEL7, but is supported on RHEL8. This is documented at https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/11/html/user_guide/chap-gcc: "On Red Hat Enterprise Linux 7, the GCC C++ compiler in Red Hat Developer Toolset still uses the old reference-counted implementation of std::string. This is done for compatibility with the Red Hat Enterprise Linux 7 system toolchain GCC. This means that some new C++17 features, such as std::pmr::string, are not available on Red Hat Enterprise Linux 7, even when using the Red Hat Developer Toolset compiler." > However, I tried to set D_GLIBCXX_USE_CXX11_ABI=0 when using Ubuntu gcc and > I was able to reproduce the segmentation fault, so it is quite probable that > this is the cause. Sorry for being unclear, that's actually what I had in mind -- see if the crash can be reproduced using -D_GLIBCXX_USE_CXX11_ABI=0/1 with Ubuntu/custom-built gcc. Without a testcase it's hard for me to figure out what exactly the issue is. Jon, do you have any ideas if there's a workaround?
Assuming that this is mixing the new ABI code with the old ABI code. libstdc++ in RHEL8 supports both ABIs, but in RHEL7, it supports only the old ABI.