[Bug libstdc++/69191] New: Wrong equality comparison between error_code and error_condition + segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69191
Bug ID: 69191
Summary: Wrong equality comparison between error_code and
error_condition + segfault
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: eyenseo at gmail dot com
Target Milestone: ---
Created attachment 37264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37264&action=edit
Precompiled minimal testcase
Greetings!
This is a bug (maybe two) regarding the comparison of std::error_condition and
std::error_code. An error_code and an error_condition with same value, message
and category name are not identified as same - but they should.
While pinpointing this bug I happened to produce a segmentation fault in
libstdc++ that is most probably part of the comparison bug. Using Clang with
libstdc++ produces the same result (including segfault). Using Clang with
libc++ produces the expected results and there is no segfault.
command line:
g++ --std=c++11 main.cpp && ./a.out
output:
code == con1: 0
code == con2: 1
con1 == con2: 0
con1 == con3: 0
con2 == con3: 0
code: value: 13
message: Permission denied
category name: generic
con1: value: 13
message: Permission denied
category name: generic
con2: value: 13
message: Permission denied
category name: generic
con3: value: 0
message: Success
category name: generic
expected:
code == con1: 1
code == con2: 1
con1 == con2: 1
con1 == con3: 1
con2 == con3: 1
code: value: 13
message: Permission denied
category name: generic
con1: value: 13
message: Permission denied
category name: generic
con2: value: 13
message: Permission denied
category name: generic
con3: value: 13
message: Permission denied
category name: generic
Source: main.cpp
#include
#include
#define equals(a, b) std::cout << #a " == " #b ": " << (a == b) << '\n';
#define print(a) \
std::cout << #a ":\tvalue: " << a.value() << "\n\tmessage: " << a.message() \
<< "\n\tcategory name: " << a.category().name() << '\n';
int main(int, char const* []) {
auto code = std::make_error_code(std::errc::permission_denied);
auto con1 = std::make_error_condition(std::errc::permission_denied);
auto con2 = code.category().default_error_condition(code.value());
auto con3 = code.default_error_condition();
equals(code, con1); // This should be true
equals(code, con2); // This is true
// equals(code, con3); // Segmentation fault
// // std::_V2::error_category::equivalent(int,
// // std::error_condition const&) const () from
// // /usr/lib/x86_64-linux-gnu/libstdc++.so.6
equals(con1, con2); // This should be true
equals(con1, con3); // This should be true
equals(con2, con3); // This should be true
std::cout << '\n';
print(code); // Same as con1 and con2
print(con1); // Same as code and con2
print(con2); // Same as code and con1
print(con3); // This should be the same as code and con1 and con2
return 0;
}
My system is:
x86_64-linux-gnu
GCC build:
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9.3-8ubuntu2~14.04' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69191 eyenseo at gmail dot com changed: What|Removed |Added Attachment #37264|0 |1 is obsolete|| --- Comment #1 from eyenseo at gmail dot com --- Created attachment 37265 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37265&action=edit Fixed precompiled testcase The other precompiled testcase had text in it.
[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69191 --- Comment #3 from eyenseo at gmail dot com --- This bug does not appear in 5.3.0 - using Arch Linux. I would like to know what a critical or major bug would be if a segfault is not? I think that a segfault is quite devastating, especially when working with error codes that should help get out of mess.
[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69191 --- Comment #4 from eyenseo at gmail dot com --- The ubuntu system I used is "normal" no testing / unstable.
[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69191 --- Comment #5 from eyenseo at gmail dot com --- (In reply to Jonathan Wakely from comment #2) > I can't reproduce this, it might be specific to Ubuntu, maybe caused by > mixing gcc 4.9 with the lisbtdc++ from gcc 5 (which would mean this is PR > 66438). The bug seems to have something to do with ubuntu indeed: This is gcc 4.9.3 with XCode (I suspect on OSX) [line: 2824] https://travis-ci.org/mnmlstc/core/jobs/98418930 This is gcc 4.9.3 on Ubuntu 12.04.5 LTS [line: 430] https://travis-ci.org/mnmlstc/core/jobs/98418950
[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69191 --- Comment #7 from eyenseo at gmail dot com --- (In reply to Jonathan Wakely from comment #6) Thanks for letting me know of the "importance-ignoring" one two less clicks next time ;) I didn't include the segfault in the precompiled file as I would not be able to get the full output that describes the bug better than the segfault. So in the end we have to assume that the travis setup and my system get the error because the Ubuntu guys build gcc wrong - but not recognisable in the build settings I included in comment #1 ?
[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69191 --- Comment #9 from eyenseo at gmail dot com --- (In reply to Jonathan Wakely from comment #8) > That only shows how your gcc compiler was built. If I understand correctly > the Ubuntu packages that provide libstdc++.so.6 come from a different build > (of a different version) from the gcc compiler executables. Well that sucks ... and now what? Close this bug and report one to ubuntu? Is there a way I can check at runtime which library I'm using?
[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69191 --- Comment #11 from eyenseo at gmail dot com --- (In reply to Jonathan Wakely from comment #10) > Use ldd to see which library is used at runtime. See what file that symlink > points to. Compare with the version numbers of the releases. > > GCC 4.9.0: libstdc++.so.6.0.20 > > GCC 5.1.0: libstdc++.so.6.0.21 Ok will do on Monday
[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69191 --- Comment #12 from eyenseo at gmail dot com --- (In reply to Jonathan Wakely from comment #10) > Use ldd to see which library is used at runtime. See what file that symlink > points to. Compare with the version numbers of the releases. > > GCC 4.9.0: libstdc++.so.6.0.20 > > GCC 5.1.0: libstdc++.so.6.0.21 It does use /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 ... why would they do that?
