Created attachment 1080420 [details] g++ -O0 -W -Wall -g --std=gnu++11 -D_GLIBCXX_USE_CXX11_ABI=1 test.cpp Description of problem: While developing a small C++ tool on Fedora 23 I discovered that when compiled with GCC 5.1.1 it would not catch exceptions as expected. For comparison, RHEL 7 with GCC 4.8 does work. See the attached test program. When run with an input file (use any text file) it should print out "caught a failure basic_ios::clear" but on Fedora 23 I get "caught an exception basic_ios::clear" Which leads me to wonder why it didn't catch the ios::failure or the std::system_error or even std::runtime_error. How could it not catch on std::runtime_error? Try with the CXX11 ABI define on and off, but the result is the same. Version-Release number of selected component (if applicable): gcc-5.1.1-4.fc23.x86_64 gcc-c++-5.1.1-4.fc23.x86_64 libgcc-5.1.1-4.fc23.x86_64 How reproducible: Always Steps to Reproduce: 1. Download the attached C++ file. 2. g++ -O0 -W -Wall -g --std=gnu++11 -D_GLIBCXX_USE_CXX11_ABI=1 test.cpp 3. ./a.out test.cpp Actual results: caught an exception basic_ios::clear Expected results: caught a failure basic_ios::clear
The failure to match ios::failure is expected (see GCC PR 66145) but I'm not sure why it passes the next two handlers as well. This should be dealt with upstream though not in the Fedora bugzilla. I'll add the test case to PR66145.
Also interesting here is that clang++ produces an a.out that catches the exception but then segfaults while trying to print e.code()
Alright. Thanks for looking at it. I assumed it was something Fedora had done to customize which GCC ABI was in use. For my other problem I'll go find clang/LLVM upstream. Although it is probably caused by the link to the libstdc++ libraries and some kind of build difference between the headers and the compiled libstdc++ library. So, not sure if that is really a clang or a GCC problem.
Clang doesn't support the abi_tag attribute, so cannot be used with _GLIBCXX_USE_CXX11_ABI They're already aware of that.
(In reply to Jonathan Wakely from comment #1) > The failure to match ios::failure is expected (see GCC PR 66145) but I'm not > sure why it passes the next two handlers as well. Doh, this is fairly obvious: in C++03 std::ios::failure derives directly from std::exception, not from std::system_error of std::runtime_error. Because the library still throws the old definition of ios::failure, it doesn't match anything except std::exception.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug is still relevant in rawhide.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This was actually fixed in F26 ages ago, and now in F28 the exception can be caught using either ABI.