From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54564 invoked by alias); 2 Nov 2018 10:33:08 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 54527 invoked by uid 89); 2 Nov 2018 10:33:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=1.3 required=5.0 tests=BAYES_50,FREEMAIL_FROM,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=ios, 6x, 71, NLM X-HELO: mail-pg1-f178.google.com Received: from mail-pg1-f178.google.com (HELO mail-pg1-f178.google.com) (209.85.215.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Nov 2018 10:33:04 +0000 Received: by mail-pg1-f178.google.com with SMTP id 32-v6so818849pgu.2 for ; Fri, 02 Nov 2018 03:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=AcqZq+NLxKQF8OuqvpCgNXvUr6ONxx6HI6SxVi9/86I=; b=u0msM7B6B5j+CobBqG+W4/Hy0K8M+V/N4z8PQHbIBvkKi/iwehDJ0eTb1eH54YKIgj 423NbXqmICsY0vzo1QGuGuE/PTu3MypoqD6QBAwk8Ez9fDXpIhS8cwDkSQH7EaPHD7YT r1Q8pdB9cUkkJkCcSaPZSsGBP3Gp9/VCPtrV+kdIVBNVDuD7mFpbikuEkha+Fh8SU3Qi HftDKeCh8SmARUNbk4Cjnr3s5ed1WBvoavcsvOn8qICjko9km7dKgkC5rowr8mM2CuIT uZDQhsWyozHQMxZConxbxtlv+n2avcpG12p2JKZNb+lo/RZ6RQi6sdGdWhINxHBlKQAh 4ltA== Return-Path: <10walls@gmail.com> Received: from ?IPv6:2001:e68:4075:c708:f64d:30ff:fe63:5a5a? ([2001:e68:4075:c708:f64d:30ff:fe63:5a5a]) by smtp.gmail.com with ESMTPSA id s186-v6sm60588063pfs.164.2018.11.02.03.33.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Nov 2018 03:33:01 -0700 (PDT) Subject: Re: iostream exceptions uncaught with CYGWIN GCC/7.3.0 To: cygwin@cygwin.com References: From: JonY <10walls@gmail.com> Openpgp: preference=signencrypt Message-ID: Date: Fri, 02 Nov 2018 10:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jtv6H4w5ZEuolrIMSugXuMyDw1ZAhAcUf" X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00026.txt.bz2 --jtv6H4w5ZEuolrIMSugXuMyDw1ZAhAcUf Content-Type: multipart/mixed; boundary="BVTAGEMxuLIXss3OTbdwxyu5zGzrTWD2Y"; protected-headers="v1" From: JonY <10walls@gmail.com> To: cygwin@cygwin.com Message-ID: Subject: Re: iostream exceptions uncaught with CYGWIN GCC/7.3.0 References: In-Reply-To: --BVTAGEMxuLIXss3OTbdwxyu5zGzrTWD2Y Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Content-length: 3979 On 11/01/2018 08:42 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote: > Hi, >=20 > Please consider the following code: >=20 > $ cat bug.cpp=20 > #include >=20 > using namespace std; >=20 > void fun() > { > string dummy; > cin >> dummy; > } >=20 >=20 > int main() > { > cout << "FAIL =3D 0x" << hex << ios::failbit << endl; > cout << "EOF =3D 0x" << hex << ios::eofbit << endl; > cout << "BAD =3D 0x" << hex << ios::badbit << endl; >=20 > cin.exceptions(ios::eofbit | ios::failbit); > try { > fun(); > } > catch (ios_base::failure&) { > cerr << "Failure caught!" << endl; > } > catch (...) { > cerr << "Failure uncaught! 0x" << hex << cin.rdstate() << endl; > } > return 0; > } >=20 > When this program is compiled and run on Linux, the exception gets caught: >=20 > $ uname -a > Linux iebdev11 3.10.0-862.14.4.el7.x86_64 #1 SMP Wed Sep 26 15:12:11 UTC = 2018 x86_64 x86_64 x86_64 GNU/Linux >=20 > $ g++ --version > g++ (GCC) 7.3.0 > Copyright (C) 2017 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOS= E. >=20 > $ g++ -Wall bug.cpp -o bug >=20 > $ ./bug < /dev/null > FAIL =3D 0x4 > EOF =3D 0x2 > BAD =3D 0x1 > Failure caught! >=20 > However, same commands on Cygwin, and the exception goes unhandled: >=20 > $ uname -a > CYGWIN_NT-10.0 NCBIPC9135 2.11.1(0.329/5/3) 2018-09-05 10:24 x86_64 Cygwin >=20 > $ gcc --version > gcc (GCC) 7.3.0 > Copyright (C) 2017 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOS= E. >=20 > $ g++ -Wall -o bug bug.cpp >=20 > $ ./bug < /dev/null > FAIL =3D 0x4 > EOF =3D 0x2 > BAD =3D 0x1 > Failure uncaught! 0x6 >=20 > We've seen this behavior before on Linux too, when the C++ ABI was change= d (w/GCC 5.x). I guess CYGWIN packages a version of C++ STDLIB whose ABI i= s incompatible with default compiler settings. >=20 > Here's some explanation of what might be the culprit. >=20 > https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html says = that: >=20 >> Using the default configuration options for GCC the default value of the= macro is 1 which causes the new ABI to be active, so to use the old ABI yo= u must explicitly define the macro to 0 before including any library header= s. >> (Be aware that some GNU/Linux distributions configure GCC 5 differently= so that the default value of the macro is 0 and users must define it to 1 = to enable the new ABI.) >=20 >> One exception type does change when using the new ABI, namely std::ios_b= ase::failure. This is necessary because the 2011 standard changed its base = class from std::exception to std::system_error, which causes its layout to = change. Exceptions due to iostream errors are thrown by a function inside l= ibstdc++.so, so whether the thrown exception uses the old std::ios_base::fa= ilure type or the new one depends on the ABI that was active when libstdc++= .so was built, not the ABI active in the user code that is using iostreams.= This means that for a given build of GCC the type thrown is fixed. In curr= ent releases the library throws a special type that can be caught by handle= rs for either the old or new type, but for GCC 7.1, 7.2 and 7.3 the library= throws the new std::ios_base::failure type, and for GCC 5.x and 6.x the li= brary throws the old type. Catch handlers of type std::ios_base::failure wi= ll only catch the exceptions if using a newer release, or if the handler is= compiled with the same ABI as the type thrown by the library. Handlers for= std::exception will always catch iostreams exceptions, because the old and= new type both inherit from std::exception. Cygwin GCC is configured and built with the old C++ ABI, I'm guess that's the problem? --BVTAGEMxuLIXss3OTbdwxyu5zGzrTWD2Y-- --jtv6H4w5ZEuolrIMSugXuMyDw1ZAhAcUf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE5QrdnbBX9Ppk4bbPcTtf4pwUXUUFAlvcJ8oACgkQcTtf4pwU XUXa6Q/+Io+N/i1jgI4Hy5hQPwsABVC32xrAv1yirT/0f2r0p0ApsptA26uHlJ01 66BcQwPvPyNWqDmQUqemK55dIyhRvSbBtoZyDuIVLGoYxD4eBb4yKaD6lwAaEFms moiHpuaHnn6KSudqSpWPZabVB76IgH/WRjygaLVlYTXJXPtR4k1hOkE/C4kn5UJV lFJkqgaEArXrnGCREZ3+DKbVjNhBEW08TFBFFyPNZANbuey+DNokDX9Z6PoxGxr7 U1PyZpptUQ3G0spG5mQQTCEBjvJsw+Paj8YKS1jPWuKQJFYIfY3AeJA+8Yo2/70H ULnz6DnULrc7OJQUOWcjKK3ecOGTdiSfxQo/D2UidRyTzFl5MLiYDl4PmTHjVQ8t 0tkinBVgONGmqkBYw/Jt2b/ihXe66BJO5nDttV7HA56bMCvaUEPUab23Agv+Ylns 5uZbEeeM2ifpsHBwhAgplj+7PzmQTQWbLQsuH4Dp8uBnJLBh27lDC7bxOOTSImih b2BxrnbexPof4V9j6JME6l+94kz5Dh8gxPIXRlu+3CLPVSd4A6CH4Scs0dF7d5Tg uvDzdN6o7ahp8bYaDOYGl2QtqhKcMTUQFxD1fCHFLcqz4ft/KLhsWGVwksotEiwK xuJn0DB2/9gfHtGAOkGNZdKxs2twmYfJFr9uKNp4t/Y+0dFdEX0= =Eal8 -----END PGP SIGNATURE----- --jtv6H4w5ZEuolrIMSugXuMyDw1ZAhAcUf--