RE: [BUG] try..catch does not work if compiled with clang 8.0

RE: [BUG] try..catch does not work if compiled with clang 8.0

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin]

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

RE: [BUG] try..catch does not work if compiled with clang 8.0

[Pavel Fedin]

 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

RE: [BUG] try..catch does not work if compiled with clang 8.0

[Pavel Fedin]

 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

Re: [BUG] try..catch does not work if compiled with clang 8.0

[Brian Inglis]

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

Re: [BUG] try..catch does not work if compiled with clang 8.0

[Dominik Strasser]

[-- 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

\x03B‹KCB”\x1c›Ø›\x19[H\x1c™\^[ܝ\x1cΈ\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÜ\x1c›Ø›\x19[\Ëš\x1d^[[\x03B‘TNˆ\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œØÜšX™H\x1a[™›Îˆ\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÛ[\vÈÝ[œÝXœØÜšX™K\Ú[\^[\x19CBƒB

RE: [BUG] try..catch does not work if compiled with clang 8.0

[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

Re: [BUG] try..catch does not work if compiled with clang 8.0

[Brian Inglis]

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

Re: [BUG] try..catch does not work if compiled with clang 8.0

[Csaba Ráduly]

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

Re: [BUG] try..catch does not work if compiled with clang 8.0

[Brian Inglis]

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

[BUG] try..catch does not work if compiled with clang 8.0

[Pavel Fedin]

 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