* [BUG] try..catch does not work if compiled with clang 8.0 [not found] <CGME20191217093504eucas1p14cced4e1f9fcec50e44e9223d1761858@eucas1p1.samsung.com> @ 2019-12-17 11:04 ` Pavel Fedin 2019-12-17 17:48 ` Brian Inglis 0 siblings, 1 reply; 10+ messages in thread From: Pavel Fedin @ 2019-12-17 11:04 UTC (permalink / raw) To: cygwin Hello! I haven't upgraded for a while and today i finally decided to do so. After rebuilding by project with clang++ 8.0 i found out that try...catch construct doesn't work. The program just gets silently aborted. Switched back to old clang++ 5.0 and it works. Also an old bug which i reported some (a while) time ago persists: uncaught throw does not print anything. OS is Windows 10 x86/64. Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG] try..catch does not work if compiled with clang 8.0 2019-12-17 11:04 ` [BUG] try..catch does not work if compiled with clang 8.0 Pavel Fedin @ 2019-12-17 17:48 ` Brian Inglis 2019-12-17 21:36 ` Csaba Ráduly 0 siblings, 1 reply; 10+ messages in thread From: Brian Inglis @ 2019-12-17 17:48 UTC (permalink / raw) To: cygwin On 2019-12-17 02:35, Pavel Fedin wrote: > I haven't upgraded for a while and today i finally decided to do so. After > rebuilding by project with clang++ 8.0 i found out that try...catch construct > doesn't work. The program just gets silently aborted. > Switched back to old clang++ 5.0 and it works. > Also an old bug which i reported some (a while) time ago persists: uncaught > throw does not print anything. > OS is Windows 10 x86/64. It is unlikely that try/catch does not work in the general case for clang++8, and your post has insufficient information to reproduce the problem. Please post a simple test case with the minimal source code required to demonstrate the error on clang++8, and check that it does not also occur with clang++5. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG] try..catch does not work if compiled with clang 8.0 2019-12-17 17:48 ` Brian Inglis @ 2019-12-17 21:36 ` Csaba Ráduly 2019-12-18 1:50 ` Brian Inglis 0 siblings, 1 reply; 10+ messages in thread From: Csaba Ráduly @ 2019-12-17 21:36 UTC (permalink / raw) To: cygwin On 17/12/2019 17:29, Brian Inglis wrote: > On 2019-12-17 02:35, Pavel Fedin wrote: >> I haven't upgraded for a while and today i finally decided to do so. After >> rebuilding by project with clang++ 8.0 i found out that try...catch construct >> doesn't work. The program just gets silently aborted. >> Switched back to old clang++ 5.0 and it works. >> Also an old bug which i reported some (a while) time ago persists: uncaught >> throw does not print anything. >> OS is Windows 10 x86/64. > It is unlikely that try/catch does not work in the general case for clang++8, > and your post has insufficient information to reproduce the problem. a.k.a. https://www.chiark.greenend.org.uk/~sgtatham/bugs.html#respect WJFFM $ cat catcher.cpp #include <stdexcept> #include <iostream> int pitcher() { throw std::runtime_error{"Ouch"}; } int main() { try { return pitcher(); } catch (std::exception const&e) { std::cout << "Caught a " << typeid(e).name() << " - " << e.what() << '\n'; return 42; } } $ g++ -v -Wall -Wpedantic -Wextra -g catcher.cpp Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: /cygdrive/i/szsz/tmpp/gcc/gcc-8.3.0-1.x86_64/src/gcc-8.3.0/configure --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-8.3.0-1.x86_64/src/gcc-8.3.0 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --enable-libitm --enable-libquadmath --enable-libquadmath-support --disable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts Thread model: posix gcc version 8.3.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wpedantic' '-Wextra' '-g' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/cc1plus.exe -quiet -v -idirafter /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../lib/../include/w32api -idirafter /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api catcher.cpp -quiet -dumpbase catcher.cpp -mtune=generic -march=x86-64 -auxbase catcher -g -Wall -Wpedantic -Wextra -version -o /tmp/cczG1NcE.s GNU C++14 (GCC) version 8.3.0 (x86_64-pc-cygwin) compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.16.1-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/include-fixed" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/include" ignoring duplicate directory "/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/include/c++ /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/include/c++/x86_64-pc-cygwin /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/include/c++/backward /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/include /usr/local/include /usr/include /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../lib/../include/w32api End of search list. GNU C++14 (GCC) version 8.3.0 (x86_64-pc-cygwin) compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.16.1-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: bed998889edfd32f5c9a3f3c8baa420d COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wpedantic' '-Wextra' '-g' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/bin/as.exe -v -o /tmp/ccCNGYho.o /tmp/cczG1NcE.s GNU assembler version 2.29.1 (x86_64-pc-cygwin) using BFD version (GNU Binutils) 2.29.1.20171006 COMPILER_PATH=/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/:/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/:/usr/lib/gcc/x86_64-pc-cygwin/:/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/:/usr/lib/gcc/x86_64-pc-cygwin/:/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/bin/ LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/:/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/lib/../lib/:/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/lib/:/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wpedantic' '-Wextra' '-g' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/collect2.exe -plugin /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/cyglto_plugin.dll -plugin-opt=/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/lto-wrapper.exe -plugin-opt=-fresolution=/tmp/ccSrxYRN.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lcygwin -plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id -m i386pep --wrap _Znwm --wrap _Znam --wrap _ZdlPv --wrap _ZdaPv --wrap _ZnwmRKSt9nothrow_t --wrap _ZnamRKSt9nothrow_t --wrap _ZdlPvRKSt9nothrow_t --wrap _ZdaPvRKSt9nothrow_t -Bdynamic --dll-search-prefix=cyg --tsaware /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../lib/crt0.o /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/crtbegin.o -L/usr/lib/gcc/x86_64-pc-cygwin/8.3.0 -L/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/lib -L/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../.. /tmp/ccCNGYho.o -lstdc++ -lgcc_s -lgcc -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lgcc_s -lgcc /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../lib/default-manifest.o /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/crtend.o COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wpedantic' '-Wextra' '-g' '-shared-libgcc' '-mtune=generic' '-march=x86-64' $ ./a.exe Caught a St13runtime_error - Ouch Csaba -- You can get very substantial performance improvements by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler So if you're looking for a completely portable, 100% standards-conformat way to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG] try..catch does not work if compiled with clang 8.0 2019-12-17 21:36 ` Csaba Ráduly @ 2019-12-18 1:50 ` Brian Inglis 2019-12-18 16:23 ` Pavel Fedin 0 siblings, 1 reply; 10+ messages in thread From: Brian Inglis @ 2019-12-18 1:50 UTC (permalink / raw) To: cygwin On 2019-12-17 13:51, Csaba Ráduly wrote: > On 17/12/2019 17:29, Brian Inglis wrote: >> On 2019-12-17 02:35, Pavel Fedin wrote: >>> I haven't upgraded for a while and today i finally decided to do so. After >>> rebuilding by project with clang++ 8.0 i found out that try...catch construct >>> doesn't work. The program just gets silently aborted. >>> Switched back to old clang++ 5.0 and it works. >>> Also an old bug which i reported some (a while) time ago persists: uncaught >>> throw does not print anything. >>> OS is Windows 10 x86/64. >> It is unlikely that try/catch does not work in the general case for clang++8, >> and your post has insufficient information to reproduce the problem. > > a.k.a. https://www.chiark.greenend.org.uk/~sgtatham/bugs.html#respect Indeed! > WJFFM >> $ cat catcher.cpp > #include <stdexcept> > #include <iostream> > > int pitcher() > { >     throw std::runtime_error{"Ouch"}; > } > > int main() > { >     try { >        return pitcher(); >     } >     catch (std::exception const&e) { >        std::cout << "Caught a " << typeid(e).name() << " - " << e.what() << '\n'; >        return 42; >     } > } > > $ g++ -v -Wall -Wpedantic -Wextra -g catcher.cpp > $ ./a.exe > Caught a St13runtime_error - Ouch The report was about clang++ 8 vs 5; tweaked source to build under 5 and 8: ... #include <typeinfo> int pitcher() { throw std::runtime_error("Ouch"); } ... but same WJFFM results: $ clang++-5.0 -g -Og -Wpedantic -Wall -Wextra -o try-catch-stc{,.cpp} $ ./try-catch-stc Caught a St13runtime_error - Ouch $ clang++-8 -g -Og -Wpedantic -Wall -Wextra -o try-catch-stc{,.cpp} $ ./try-catch-stc Caught a St13runtime_error - Ouch -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [BUG] try..catch does not work if compiled with clang 8.0 2019-12-18 1:50 ` Brian Inglis @ 2019-12-18 16:23 ` Pavel Fedin 2019-12-18 18:54 ` Dominik Strasser 2019-12-18 19:32 ` Brian Inglis 0 siblings, 2 replies; 10+ messages in thread From: Pavel Fedin @ 2019-12-18 16:23 UTC (permalink / raw) To: Brian.Inglis, cygwin Well, it turned out more complicated than i thought. Here is the reduced reproducer: --- cut catch_test.cpp --- #include <stdexcept> #include <iostream> #include <vector> #include <string> #include <fstream> void from_file(const std::string &filepath, std::vector<int8_t> &data); int main() { try { std::vector<int8_t> data; from_file("no_such_file.bin", data); std::cout << "Success ???" << std::endl; } catch (const std::exception &e) { std::cout << "std::exception: " << e.what() << std::endl; } return 0; } --- cut catch_test.cpp --- --- cut catch_test_2.cpp --- #include <stdexcept> #include <iostream> #include <vector> #include <string> #include <fstream> using namespace std; template <typename T> void from_file_impl(const string &filepath, vector<T> &data) { // data.clear(); std::ifstream ifs(filepath.c_str()); if (ifs.rdstate() & ifstream::failbit) { throw std::runtime_error("Error in reading " + filepath); } /* T buffer; while (ifs.read(reinterpret_cast<char *>(&buffer), sizeof(T))) { data.push_back(buffer); }*/ } void from_file(const string &filepath, vector<int8_t> &data) { from_file_impl(filepath, data); } --- cut catch_test_2.cpp --- --- cut console log --- CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test $ clang++-8 catch_test.cpp catch_test_2.cpp -g -o catch_test CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test $ ./catch_test CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test $ g++.exe catch_test.cpp catch_test_2.cpp -g -o catch_test CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test $ ./catch_test CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test $ clang++-5.0 catch_test.cpp catch_test_2.cpp -g -o catch_test CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test $ ./catch_test std::exception: Error in reading no_such_file.bin CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test $ --- cut console log --- So, the problem actually reproduces with both clang 8 and gcc (7.4.0 on my system). clang 5 works fine. You could also be interested in strace (here is end of the output only, the beginning is quite long and not very interesting): --- cut --- 22301 238862 [main] catch_test 6078 seterrno_from_nt_status: /home/corinna/src/cygwin/cygwin-3.1.0/cygwin-3.1.0-1.x86_64/src/newlib-cygwin/winsup/cygwin/fhandler.cc:724 status 0xC0000034 -> windows error 2 75 238937 [main] catch_test 6078 geterrno_from_win_error: windows error 2 == errno 2 42 238979 [main] catch_test 6078 fhandler_base::open: 0xC0000034 = NtCreateFile (0x10, 0x80100000, \??\D:\Projects\Test\no_such_file.bin, io, NULL, 0x0, 0x7, 0x1, 0x4020, NULL, 0) 78 239057 [main] catch_test 6078 fhandler_base::open: 0 = fhandler_base::open(\??\D:\Projects\Test\no_such_file.bin, 0x108000) 41 239098 [main] catch_test 6078 fhandler_base::open_fs: 0 = fhandler_disk_file::open(\??\D:\Projects\Test\no_such_file.bin, 0x8000) 99 239197 [main] catch_test 6078 open: -1 = open(no_such_file.bin, 0x8000), errno 2 --- Process 2620 (pid: 6078), exception 20474343 at 00007ff8c73fa388 --- Process 2620 (pid: 6078) thread 12836 exited with status 0x20474343 --- Process 2620 (pid: 6078) thread 3972 exited with status 0x20474343 --- Process 2620 (pid: 6078) thread 15568 exited with status 0x20474343 --- Process 2620 (pid: 6078) thread 5428 exited with status 0x20474343 --- Process 2620 (pid: 6078) thread 2364 exited with status 0x20474343 --- Process 2620 (pid: 6078) thread 16008 exited with status 0x20474343 --- Process 2620 exited with status 0x20474343 --- cut --- So, a Windows exception is reported, then the whole thing silently quits. I have an impression that it has to do with the bug i previously reported (and someone here claimed he could reproduce it) Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia > -----Original Message----- > From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of Brian Inglis > Sent: Wednesday, December 18, 2019 3:05 AM > To: cygwin@cygwin.com > Subject: Re: [BUG] try..catch does not work if compiled with clang 8.0 > > On 2019-12-17 13:51, Csaba Ráduly wrote: > > On 17/12/2019 17:29, Brian Inglis wrote: > >> On 2019-12-17 02:35, Pavel Fedin wrote: > >>> I haven't upgraded for a while and today i finally decided to do so. After > >>> rebuilding by project with clang++ 8.0 i found out that try...catch construct > >>> doesn't work. The program just gets silently aborted. > >>> Switched back to old clang++ 5.0 and it works. > >>> Also an old bug which i reported some (a while) time ago persists: uncaught > >>> throw does not print anything. > >>> OS is Windows 10 x86/64. > >> It is unlikely that try/catch does not work in the general case for clang++8, > >> and your post has insufficient information to reproduce the problem. > > > > a.k.a. https://www.chiark.greenend.org.uk/~sgtatham/bugs.html#respect > > Indeed! > > > WJFFM > >> $ cat catcher.cpp > > #include <stdexcept> > > #include <iostream> > > > > int pitcher() > > { > > throw std::runtime_error{"Ouch"}; > > } > > > > int main() > > { > > try { > > return pitcher(); > > } > > catch (std::exception const&e) { > > std::cout << "Caught a " << typeid(e).name() << " - " << e.what() << '\n'; > > return 42; > > } > > } > > > > $ g++ -v -Wall -Wpedantic -Wextra -g catcher.cpp > > > $ ./a.exe > > Caught a St13runtime_error - Ouch > > The report was about clang++ 8 vs 5; tweaked source to build under 5 and 8: > ... > #include <typeinfo> > > int pitcher() > { > throw std::runtime_error("Ouch"); > } > ... > > but same WJFFM results: > > $ clang++-5.0 -g -Og -Wpedantic -Wall -Wextra -o try-catch-stc{,.cpp} > $ ./try-catch-stc > Caught a St13runtime_error - Ouch > > $ clang++-8 -g -Og -Wpedantic -Wall -Wextra -o try-catch-stc{,.cpp} > $ ./try-catch-stc > Caught a St13runtime_error - Ouch > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > > -- > Problem reports: https://protect2.fireeye.com/url?k=b437d571-e9e489fe-b4365e3e- > 0cc47a31ce52-fd9c07d8a89a97f5&u=http://cygwin.com/problems.html > FAQ: https://protect2.fireeye.com/url?k=2e1da12d-73cefda2-2e1c2a62- > 0cc47a31ce52-67f7089b29388f59&u=http://cygwin.com/faq/ > Documentation: https://protect2.fireeye.com/url?k=3f2aeb24-62f9b7ab-3f2b606b- > 0cc47a31ce52-9528889b998d683e&u=http://cygwin.com/docs.html > Unsubscribe info: https://protect2.fireeye.com/url?k=b1682add-ecbb7652-b169a192- > 0cc47a31ce52-e02defedfa7edb6b&u=http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG] try..catch does not work if compiled with clang 8.0 2019-12-18 16:23 ` Pavel Fedin @ 2019-12-18 18:54 ` Dominik Strasser 2019-12-18 19:32 ` Brian Inglis 1 sibling, 0 replies; 10+ messages in thread From: Dominik Strasser @ 2019-12-18 18:54 UTC (permalink / raw) To: cygwin [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 9020 bytes --] Hi, I am experiencing similar problems with my software. I am using Cygwin's mingw g++. The issue is very dependent on the files which are compiled, and how they are compiled. (-Ox, -g, ...) My suspicion is that the problem is with ld and the merging of the exception region tables, but was never able to track down the issue. However I cannot reproduce your issue on my machines. I tried: GNU C++14 (GCC) version 7.4.0 (x86_64-pc-cygwin) on a VM CYGWIN_NT-6.1 xxx 2.11.2(0.329/5/3) 2018-11-08 14:34 x86_64 Cygwin and GNU C++14 (GCC) Version 7.4.0 (x86_64-pc-cygwin) on my laptop CYGWIN_NT-10.0 xxx 3.1.1(0.340/5/3) 2019-12-18 09:28 x86_64 Cygwin with very different cygwin versions. Both of them give ./catch_test std::exception: Error in reading no_such_file.bin I tried my default compiler, too: GNU C++14 (GCC) version 7.4.0 (x86_64-w64-mingw32) No problems with this setup either. Can you maybe post your binary so I could try it with this one. Best regards Dominik Am 18.12.2019 um 16:10 schrieb Pavel Fedin: > Well, it turned out more complicated than i thought. Here is the reduced reproducer: > --- cut catch_test.cpp --- > #include <stdexcept> > #include <iostream> > #include <vector> > #include <string> > #include <fstream> > > void from_file(const std::string &filepath, std::vector<int8_t> &data); > > int main() > { > try > { > std::vector<int8_t> data; > > from_file("no_such_file.bin", data); > std::cout << "Success ???" << std::endl; > } > catch (const std::exception &e) > { > std::cout << "std::exception: " << e.what() << std::endl; > } > > return 0; > } > --- cut catch_test.cpp --- > --- cut catch_test_2.cpp --- > #include <stdexcept> > #include <iostream> > #include <vector> > #include <string> > #include <fstream> > > using namespace std; > > template <typename T> void from_file_impl(const string &filepath, vector<T> &data) > { > // data.clear(); > > std::ifstream ifs(filepath.c_str()); > if (ifs.rdstate() & ifstream::failbit) > { > throw std::runtime_error("Error in reading " + filepath); > } > > /* T buffer; > > while (ifs.read(reinterpret_cast<char *>(&buffer), sizeof(T))) > { > data.push_back(buffer); > }*/ > } > > void from_file(const string &filepath, vector<int8_t> &data) { from_file_impl(filepath, data); } > --- cut catch_test_2.cpp --- > --- cut console log --- > CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test > $ clang++-8 catch_test.cpp catch_test_2.cpp -g -o catch_test > > CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test > $ ./catch_test > > CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test > $ g++.exe catch_test.cpp catch_test_2.cpp -g -o catch_test > > CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test > $ ./catch_test > > CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test > $ clang++-5.0 catch_test.cpp catch_test_2.cpp -g -o catch_test > > CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test > $ ./catch_test > std::exception: Error in reading no_such_file.bin > > CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test > $ > --- cut console log --- > > So, the problem actually reproduces with both clang 8 and gcc (7.4.0 on my system). clang 5 works fine. > > You could also be interested in strace (here is end of the output only, the beginning is quite long and not very interesting): > --- cut --- > 22301 238862 [main] catch_test 6078 seterrno_from_nt_status: /home/corinna/src/cygwin/cygwin-3.1.0/cygwin-3.1.0-1.x86_64/src/newlib-cygwin/winsup/cygwin/fhandler.cc:724 status 0xC0000034 -> windows error 2 > 75 238937 [main] catch_test 6078 geterrno_from_win_error: windows error 2 == errno 2 > 42 238979 [main] catch_test 6078 fhandler_base::open: 0xC0000034 = NtCreateFile (0x10, 0x80100000, \??\D:\Projects\Test\no_such_file.bin, io, NULL, 0x0, 0x7, 0x1, 0x4020, NULL, 0) > 78 239057 [main] catch_test 6078 fhandler_base::open: 0 = fhandler_base::open(\??\D:\Projects\Test\no_such_file.bin, 0x108000) > 41 239098 [main] catch_test 6078 fhandler_base::open_fs: 0 = fhandler_disk_file::open(\??\D:\Projects\Test\no_such_file.bin, 0x8000) > 99 239197 [main] catch_test 6078 open: -1 = open(no_such_file.bin, 0x8000), errno 2 > --- Process 2620 (pid: 6078), exception 20474343 at 00007ff8c73fa388 > --- Process 2620 (pid: 6078) thread 12836 exited with status 0x20474343 > --- Process 2620 (pid: 6078) thread 3972 exited with status 0x20474343 > --- Process 2620 (pid: 6078) thread 15568 exited with status 0x20474343 > --- Process 2620 (pid: 6078) thread 5428 exited with status 0x20474343 > --- Process 2620 (pid: 6078) thread 2364 exited with status 0x20474343 > --- Process 2620 (pid: 6078) thread 16008 exited with status 0x20474343 > --- Process 2620 exited with status 0x20474343 > --- cut --- > So, a Windows exception is reported, then the whole thing silently quits. > I have an impression that it has to do with the bug i previously reported (and someone here claimed he could reproduce it) > > Kind regards, > Pavel Fedin > Senior Engineer > Samsung Electronics Research center Russia > > >> -----Original Message----- >> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of Brian Inglis >> Sent: Wednesday, December 18, 2019 3:05 AM >> To: cygwin@cygwin.com >> Subject: Re: [BUG] try..catch does not work if compiled with clang 8.0 >> >> On 2019-12-17 13:51, Csaba Ráduly wrote: >>> On 17/12/2019 17:29, Brian Inglis wrote: >>>> On 2019-12-17 02:35, Pavel Fedin wrote: >>>>> I haven't upgraded for a while and today i finally decided to do so. After >>>>> rebuilding by project with clang++ 8.0 i found out that try...catch construct >>>>> doesn't work. The program just gets silently aborted. >>>>> Switched back to old clang++ 5.0 and it works. >>>>> Also an old bug which i reported some (a while) time ago persists: uncaught >>>>> throw does not print anything. >>>>> OS is Windows 10 x86/64. >>>> It is unlikely that try/catch does not work in the general case for clang++8, >>>> and your post has insufficient information to reproduce the problem. >>> a.k.a. https://www.chiark.greenend.org.uk/~sgtatham/bugs.html#respect >> Indeed! >>> WJFFM >>>> $ cat catcher.cpp >>> #include <stdexcept> >>> #include <iostream> >>> int pitcher() >>> { >>> throw std::runtime_error{"Ouch"}; >>> } >>> int main() >>> { >>> try { >>> return pitcher(); >>> } >>> catch (std::exception const&e) { >>> std::cout << "Caught a " << typeid(e).name() << " - " << e.what() << '\n'; >>> return 42; >>> } >>> } >>> $ g++ -v -Wall -Wpedantic -Wextra -g catcher.cpp >>> $ ./a.exe >>> Caught a St13runtime_error - Ouch >> The report was about clang++ 8 vs 5; tweaked source to build under 5 and 8: >> ... >> #include <typeinfo> >> int pitcher() >> { >> throw std::runtime_error("Ouch"); >> } >> ... >> but same WJFFM results: >> $ clang++-5.0 -g -Og -Wpedantic -Wall -Wextra -o try-catch-stc{,.cpp} >> $ ./try-catch-stc >> Caught a St13runtime_error - Ouch >> $ clang++-8 -g -Og -Wpedantic -Wall -Wextra -o try-catch-stc{,.cpp} >> $ ./try-catch-stc >> Caught a St13runtime_error - Ouch >> -- >> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada >> This email may be disturbing to some readers as it contains >> too much technical detail. Reader discretion is advised. >> -- >> Problem reports: https://protect2.fireeye.com/url?k=b437d571-e9e489fe-b4365e3e- >> 0cc47a31ce52-fd9c07d8a89a97f5&u=http://cygwin.com/problems.html >> FAQ: https://protect2.fireeye.com/url?k=2e1da12d-73cefda2-2e1c2a62- >> 0cc47a31ce52-67f7089b29388f59&u=http://cygwin.com/faq/ >> Documentation: https://protect2.fireeye.com/url?k=3f2aeb24-62f9b7ab-3f2b606b- >> 0cc47a31ce52-9528889b998d683e&u=http://cygwin.com/docs.html >> Unsubscribe info: https://protect2.fireeye.com/url?k=b1682add-ecbb7652-b169a192- >> 0cc47a31ce52-e02defedfa7edb6b&u=http://cygwin.com/ml/#unsubscribe-simple > > > > > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Dominik Strasser | Phone: +49 89 99013-436 OneSpin Solutions GmbH | Fax: +49 89 99013-100 Nymphenburgerstr. 20a 80335 Muenchen | dominik.strasser@onespin.com Geschaeftsfuehrung: Dr. Raik Brinkmann, Oliver Habeck Vorsitzender des Beirats: Paul Hill Sitz: Muenchen; Amtsgericht Muenchen HRB 139464 UstID#: DE 814413215 \x03BKCB\x1cØ\x19[H\x1c\^[Ü\x1cÎ\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0eËØÞYÝÚ[ÛÛKÜ\x1cØ\x19[\Ë\x1d^[[\x03BTN\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0eËØÞYÝÚ[ÛÛKÙ\KÃB^[ØÝ[Y[\x18]\x1a[Û\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0eËØÞYÝÚ[ÛÛKÙ^[ØÜË\x1d^[[\x03B[ÝXØÜXH\x1a[Î\b\b\b\b\b\x1a\x1d\x1d\x1c\x0eËØÞYÝÚ[ÛÛKÛ[\vÈÝ[ÝXØÜXK\Ú[\^[\x19CBB ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG] try..catch does not work if compiled with clang 8.0 2019-12-18 16:23 ` Pavel Fedin 2019-12-18 18:54 ` Dominik Strasser @ 2019-12-18 19:32 ` Brian Inglis 2019-12-19 10:30 ` Pavel Fedin 2019-12-19 17:12 ` Pavel Fedin 1 sibling, 2 replies; 10+ messages in thread From: Brian Inglis @ 2019-12-18 19:32 UTC (permalink / raw) To: cygwin On 2019-12-18 08:10, Pavel Fedin wrote: > Well, it turned out more complicated than i thought. Here is the reduced > reproducer: > --- cut catch_test.cpp --- > #include <stdexcept> > #include <iostream> > #include <vector> > #include <string> > #include <fstream> > > void from_file(const std::string &filepath, std::vector<int8_t> &data); > > int main() > { > try > { > std::vector<int8_t> data; > > from_file("no_such_file.bin", data); > std::cout << "Success ???" << std::endl; > } > catch (const std::exception &e) > { > std::cout << "std::exception: " << e.what() << std::endl; > } > > return 0; > } > --- cut catch_test.cpp --- > --- cut catch_test_2.cpp --- > #include <stdexcept> > #include <iostream> > #include <vector> > #include <string> > #include <fstream> > > using namespace std; > > template <typename T> void from_file_impl(const string &filepath, vector<T> &data) > { > // data.clear(); > > std::ifstream ifs(filepath.c_str()); > if (ifs.rdstate() & ifstream::failbit) > { > throw std::runtime_error("Error in reading " + filepath); > } > > /* T buffer; > > while (ifs.read(reinterpret_cast<char *>(&buffer), sizeof(T))) > { > data.push_back(buffer); > }*/ > } > > void from_file(const string &filepath, vector<int8_t> &data) { from_file_impl(filepath, data); } > --- cut catch_test_2.cpp --- > --- cut console log --- > CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test > $ clang++-8 catch_test.cpp catch_test_2.cpp -g -o catch_test > > CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test > $ ./catch_test > > CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test > $ g++.exe catch_test.cpp catch_test_2.cpp -g -o catch_test > > CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test > $ ./catch_test > > CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test > $ clang++-5.0 catch_test.cpp catch_test_2.cpp -g -o catch_test > > CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test > $ ./catch_test > std::exception: Error in reading no_such_file.bin > > CORP+p.fedin@P-FEDIN01 /cygdrive/d/Projects/Test > $ > --- cut console log --- > > So, the problem actually reproduces with both clang 8 and gcc (7.4.0 on my > system). clang 5 works fine. Confirmed with clang++ 8, but WJFFM with g++ 7.4.0 and reports exception (below). Warnings from clang++ and g++: $ clang++-8/5.0 -g -Og -Wpedantic -Wall -Wextra -o try-catch-stc-1{,.cpp} try-catch-stc-2.cpp try-catch-stc-2.cpp:9:78: warning: unused parameter 'data' [-Wunused-parameter] template <typename T> void from_file_impl(const string &filepath, vector<T> &data) ^ 1 warning generated. $ g++ -g -Og -Wpedantic -Wall -Wextra -o try-catch-stc-1{,.cpp} try-catch-stc-2.cpp try-catch-stc-2.cpp: In instantiation of âvoid from_file_impl(const string&, std::vector<T>&) [with T = signed char; std::string = std::basic_string<char>]â: try-catch-stc-2.cpp:19:34: required from here try-catch-stc-2.cpp:9:78: warning: unused parameter âdataâ [-Wunused-parameter] template <typename T> void from_file_impl(const string &filepath, vector<T> &data) $ ./try-catch-stc-1 exception: Error in reading no_such_file.bin > So, a Windows exception is reported, then the whole thing silently quits. > I have an impression that it has to do with the bug I previously reported > (and someone here claimed he could reproduce it) Please provide a link to the Cygwin ML message; is it this, confirmed by Takashi Yano: https://cygwin.com/ml/cygwin/2019-10/msg00038.html -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [BUG] try..catch does not work if compiled with clang 8.0 2019-12-18 19:32 ` Brian Inglis @ 2019-12-19 10:30 ` Pavel Fedin 2019-12-19 17:12 ` Pavel Fedin 1 sibling, 0 replies; 10+ messages in thread From: Pavel Fedin @ 2019-12-19 10:30 UTC (permalink / raw) To: Brian.Inglis, cygwin Hello! > Confirmed with clang++ 8 Good! Meanwhile i've tried to investigate it myself a bit and here's some more info: 1. With clang 8 __cxa_throw() ends up in Windows RaiseException(); with clang 5 it simply doesn't make it there. I guess there's some problem with interpreting unwind info. 2. strace actually reports "exception XXX at YYY" twice with clang 5, when the code is working. clang 8 code reports this only once before dying. 3. The problem is triggered by a combination of template (from_file_impl) and "if" condition inside. If you remove any of these features (e. g. throw unconditionally or move the code from template into from_file()), the code starts working. Perhaps even generic clang 8 bug. > but WJFFM with g++ 7.4.0 and reports exception (below). Yes, confirmed. I was tricked by the fact that clang does not append ".exe" to the binary name automatically (isn't it a small bug too?). So that shell sequence: $ clang++-8 catch_test.cpp catch_test_2.cpp -g -o catch_test $ g++ catch_test.cpp catch_test_2.cpp -g -o catch_test (note that no .exe suffix is given to -o !!!) ...produces two files, one named "catch_test" and another named "catch_test.exe". Attempt to execute "./catch_test" in the shell first tries to find the exact name and succeeds, always running the broken binary made by clang. > > So, a Windows exception is reported, then the whole thing silently quits. > > I have an impression that it has to do with the bug I previously reported > > (and someone here claimed he could reproduce it) > > Please provide a link to the Cygwin ML message; is it this, confirmed by Takashi > Yano: > > https://cygwin.com/ml/cygwin/2019-10/msg00038.html Yes, that one. Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [BUG] try..catch does not work if compiled with clang 8.0 2019-12-18 19:32 ` Brian Inglis 2019-12-19 10:30 ` Pavel Fedin @ 2019-12-19 17:12 ` Pavel Fedin 1 sibling, 0 replies; 10+ messages in thread From: Pavel Fedin @ 2019-12-19 17:12 UTC (permalink / raw) To: Brian.Inglis, cygwin Hello! I've done some more research on this particular bug. > > > I have an impression that it has to do with the bug I previously reported > > > (and someone here claimed he could reproduce it) > > > > Please provide a link to the Cygwin ML message; is it this, confirmed by Takashi > > Yano: > > > > https://cygwin.com/ml/cygwin/2019-10/msg00038.html > > Yes, that one. So, first of all, _GCC_specific_handler() inside libgcc never returns anything but ExceptionContinueSearch . However it's clear from __cxa_throw() code that the control must go past RaiseException() in order to reach std::terminate(). Study of 32-bit version behavior with gdb confirms that indeed this is the expected control flow. So, i conclude that ExceptionContinueExecution should be issued somewhere else. Again, with gdb and grep i've figured out that exception::handle() inside cygwin1.dll is responsible for it. Here is where behavior significantly differs between 64 and 32-bit versions. With 32-bit version the exception handling ends here: --- cut --- #ifdef __i386__ if (me.andreas) me.andreas->leave (); /* Return from a "san" caught fault */ #endif --- cut --- leave() never returns, the exception gets re-thrown a couple of times (every time ending up in this leave()), then RaiseException() eventually returns and std::terminate() is called. With x68-64 version it seems to go through switch (e->ExceptionCode) and return ExceptionContinueSearch from "default" case. There are no more handlers, so the process is terminated. ExceptionCode is 0x20474343 (" GCC" ?) Apparently there's something missing and/or not working regarding this "san Andreas" trick. I don't know what it is and have no time to research since i'm leaving for vacation till January.So won't be responsive for some time, sorry. Hopefully my study will give you some hints. Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [BUG] try..catch does not work if compiled with clang 8.0 @ 2019-12-18 17:46 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin 0 siblings, 0 replies; 10+ messages in thread From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin @ 2019-12-18 17:46 UTC (permalink / raw) To: 'cygwin@cygwin.com' The problem maybe in ABI incompatibility with older C++ (not C++11-compliant) run-time libraries: In C++11 class inheritance for many standard exceptions has changed greatly, so all the run-time libraries must be recompiled to match the inheritance seen by the compiler in the header files (when it compiles the executable). My $0.02 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-12-19 14:20 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20191217093504eucas1p14cced4e1f9fcec50e44e9223d1761858@eucas1p1.samsung.com> 2019-12-17 11:04 ` [BUG] try..catch does not work if compiled with clang 8.0 Pavel Fedin 2019-12-17 17:48 ` Brian Inglis 2019-12-17 21:36 ` Csaba Ráduly 2019-12-18 1:50 ` Brian Inglis 2019-12-18 16:23 ` Pavel Fedin 2019-12-18 18:54 ` Dominik Strasser 2019-12-18 19:32 ` Brian Inglis 2019-12-19 10:30 ` Pavel Fedin 2019-12-19 17:12 ` Pavel Fedin 2019-12-18 17:46 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).