unhandled C++ exceptions not propagating

[Ken Brown]

On 8/16/2020 9:52 AM, Takashi Yano via Cygwin wrote:
> On Sun, 16 Aug 2020 09:21:24 -0400
> Ken Brown via Cygwin <cygwin@cygwin.com> wrote:
>> On 8/15/2020 11:53 PM, Takashi Yano via Cygwin wrote:
>>> On Sat, 15 Aug 2020 20:38:01 -0300
>>> David McFarland via Cygwin <cygwin@cygwin.com> wrote:
>>>>
>>>> I was just debugging a c++ app (b2 build system from boost), and noticed
>>>> that it would appear to exit unexpectedly without an error.  This turned
>>>> out to be when an unhandled C++ exception was thrown.
>>>>
>>>> On a fresh install of cygwin with gcc-g++, this program will throw an
>>>> exception from the std::string constructor:
>>>>
>>>> c++ -x c++ - <<END
>>>> #include <string>
>>>> int main() { std::string str(nullptr); return 0; }
>>>> END
>>>>
>>>> When it's executed from the shell it returns zero, but execution stops
>>>> at the exception.
>>>>
>>>> $ ./a; echo $?
>>>> 0
>>>>
>>>> When executed under gdb, the exception is caught, and the process exits
>>>> non-zero when continued:
>>>>
>>>> (gdb) r
>>>> Starting program: /home/corngood/a
>>>> [New Thread 4300.0x1390]
>>>> [New Thread 4300.0x1d24]
>>>> [New Thread 4300.0x1d48]
>>>> [New Thread 4300.0x80c]
>>>> gdb: unknown target exception 0x20474343 at 0x7ff8d2cfa799
>>>> Thread 1 "a" received signal ?, Unknown signal.
>>>> 0x00007ff8d2cfa799 in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
>>>> (gdb) c
>>>> Continuing.
>>>> [Thread 4300.0x1d24 exited with code 541541187]
>>>> [Thread 4300.0x1870 exited with code 541541187]
>>>> [Thread 4300.0x1d48 exited with code 541541187]
>>>> [Thread 4300.0x1390 exited with code 541541187]
>>>> [Inferior 1 (process 4300) exited with code 04021641503]
>>>> (gdb)
>>>>
>>>> When executed under strace, it exits with an error as expected:
>>>>
>>>> $ strace -o /dev/null a; echo $?
>>>> 67
>>>>
>>>> That's as far as I've investigated so far.
>>>
>>> Is this the same issue with
>>> https://cygwin.com/pipermail/cygwin/2019-October/242795.html ?
>>>
>>> As far as I tested, this does not occur in 32-bit cygwin.
>>
>> This doesn't seem to be a new issue.  I found the following report from 6 years
>> ago, on Cygwin 1.7.30 with GCC 4.9.0:
>>
>> https://stackoverflow.com/questions/24402412/program-executed-on-cygwin-does-not-report-a-thrown-exception
> 
> Thanks for the information. But I still wonder why 32-bit and 64-bit
> cygwin behave differently.

I'm no C++ expert, but my understanding after a brief internet search is that an 
uncaught exception is supposed to cause std::terminate to be called.  So I 
installed gcc-debuginfo and ran the OP's test case under gdb with a breakpoint 
at 'terminate'.  On 32-bit Cygwin I got the expected behavior:

Thread 1 "exception_test" hit Breakpoint 1, std::terminate ()
     at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/eh_terminate.cc:96
96        __atomic_load (&__terminate_handler, &func, __ATOMIC_ACQUIRE);
(gdb) bt
#0  std::terminate ()
     at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/eh_terminate.cc:96
#1  0x57c45909 in __cxxabiv1::__cxa_throw (obj=obj@entry=0x800396e8,
     tinfo=tinfo@entry=0x57c646a8 <typeinfo for std::logic_error>,
     dest=0x57be6c60 <std::logic_error::~logic_error()>)
     at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/eh_throw.cc:95
#2  0x57c49223 in std::__throw_logic_error (
     __s=__s@entry=0x57c60160 <cplus_demangle_builtin_types+10272> "basic_string::
_S_construct null not valid")
     at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/src/c++11/functexcept.cc:66
[...]

On 64-bit Cygwin, however, I got the behavior reported by the OP:

gdb: unknown target exception 0x20474343 at 0x7ff8cccca719

Thread 1 "exception_test" received signal ?, Unknown signal.
0x00007ff8cccca719 in RaiseException () from /c/WINDOWS/System32/KERNELBASE.dll
(gdb) c
Continuing.
[Thread 4508.0x3e20 exited with code 541541187]
[Thread 4508.0x5bc exited with code 541541187]
[Thread 4508.0x5ee8 exited with code 541541187]
[Thread 4508.0x1cd0 exited with code 541541187]
[Inferior 1 (process 4508) exited with code 04021641503]

Note that the breakpoint at 'terminate' is not reached.  I tried putting a 
breakpoint at __cxa_throw and stepping through from there, but I don't really 
understand what's going on.  Someone who knows the innards of exception handling 
will have to look at this.

Ken