[Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating

[Ken Brown]

On 8/17/2020 4:40 PM, Ken Brown via Cygwin wrote:
> On 8/17/2020 3:06 PM, Ken Brown via Cygwin wrote:
>> On 8/17/2020 2:13 PM, Corinna Vinschen wrote:
>>> On Aug 17 13:36, Ken Brown via Cygwin wrote:
>>>> On 8/16/2020 6:38 PM, Ken Brown via Cygwin wrote:
>>>>> One further comment, and then I'll shut up
>>>>
>>>> I lied.
>>>
>>> ...which is ok.
>>>
>>>>> and leave it to people who know what they're talking about: In the
>>>>> 64-bit case, the function _Unwind_RaiseException in libgcc/unwind-seh.c
>>>>> gets called, and it calls the Win32 function RaiseException as follows:
>>>>>
>>>>>     RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *)&exc);
>>>>>
>>>>> Then the following comment appears:
>>>>>
>>>>>     /* The exception handler installed in crt0 will continue any GCC
>>>>>        exception that reaches there (and isn't marked non-continuable).
>>>>>        Returning allows the C++ runtime to call std::terminate.  */
>>>>>
>>>>> Apparently this doesn't actually happen.
>>>>
>>>> I'm beginning to think this is a bug in the Cygwin build of gcc.  The file
>>>> unwind-seh.c is compiled on 64-bit Cygwin because __SEH__ is defined.  But
>>>> it makes assumptions, such as those in the comment quoted above, that are
>>>> not valid on Cygwin.
>>>>
>>>> In fact, if you look at the main exception handler on Cygwin
>>>> (exceptions.cc:626), it is clear that the exception code STATUS_GCC_THROW
>>>> does not lead to continuation.  It falls under the default case:
>>>>
>>>>      default:
>>>>        /* If we don't recognize the exception, we have to assume that
>>>>      we are doing structured exception handling, and we let
>>>>      something else handle it.  */
>>>>        return ExceptionContinueSearch;
>>>>
>>>> [STATUS_GCC_THROW is 0x20474343, which shows up in the gdb output above as
>>>> an unknown target exception.]
>>>>
>>>> So it seems to me that either Cygwin's exception handler has to learn to
>>>> handle the exception codes defined in unwind-seh.c, or else gcc should be
>>>> built with __SEH__ undefined.
>>>>
>>>> JonY, Achim, Corinna, am I missing something?
>>>
>>> This stuff isn't really my strong point.  IIUC the above comment correctly,
>>> we might get away with adding another case to the exception handler switch:
>>>
>>>    #define STATUS_GCC_THROW 0x20474343
>>>    case STATUS_GCC_THROW:
>>>      return ExceptionContinueExecution;
>>>
>>> Did you try that, by any chance?
>>
>> No, I didn't.  It might well solve the immediate problem of this bug report. 
>> But then there are two other exception codes that occur in unwind-seh.c that 
>> we would also have to deal with: STATUS_GCC_UNWIND    and STATUS_GCC_FORCED. 
>> Someone would have to look at their uses and figure out what, if anything, 
>> Cygwin should do with them.
> 
> This isn't an issue after all.  The comment I quoted above refers to all GCC 
> exceptions, not just STATUS_GCC_THROW.  I'll submit a patch after testing.

I've sent the patch.  The output of the OP's test case is now the same on 64-bit 
as on 32-bit:

$ ./a
terminate called after throwing an instance of 'std::logic_error'
   what():  basic_string::_S_construct null not valid
Aborted (core dumped)

Ken