Ok, I tried an experiment, and I believe I found the root cause of the
problem. It appears that CMake is using the compiler option /Ehc, which
assumes that C extern functions will never throw an exception. Since
ThrowExceptionC is declared as an extern C function, the compiler is not
generating any code for exception handling, causing the problem. The fix is
to figure out how to change the compiler options getting used.
Rick
On Fri, Nov 20, 2020 at 9:21 AM Rick McGuire <object.r...@gmail.com> wrote:
> A deeper dive. This definitely looks like a bug in the Windows throw/catch
> handling. After the exception is thrown, I see ApiContext destructors
> running for two API calls from the StemHanderl destructor, but never see
> the destructor for the ThrowException2 stack frame getting called. This
> leaves the semaphore in a bad state.
>
> Rick
>
> On Fri, Nov 20, 2020 at 9:12 AM Rick McGuire <object.r...@gmail.com>
> wrote:
>
>> I think I figured it out. After the exception is thrown, the destructor
>> for the StemHandler variable gets invoked, which ends up making a call to
>> several APIs while in the state where the kernel semaphore is held. This
>> acquires, and then releases the semaphore, which has the effect that the
>> ApiContext ends up not releasing the semaphore when invoked because it
>> doesn't believe it is holding it. This looks like a Windows bug or compiler
>> bug to me, because the destructors are getting invoked out of order. That
>> is, the StemHandler destructor appears to be invoked BEFORE the ApiContext
>> one for the ThrowException2() call. We may need to continue to rely on
>> using the RaiseExceptionX calls.
>>
>> Rick
>>
>> On Fri, Nov 20, 2020 at 9:03 AM Erich Steinböck <
>> erich.steinbo...@gmail.com> wrote:
>>
>>> This is Windows-only.
>>> But it also seems to be SysFileTree-specific - see below code sample.
>>>
>>> ~~~
>>> i = 1
>>> start:
>>> signal on syntax
>>> select case i
>>> when 1 then call SysGetKey "z"
>>> when 2 then call SysSearchPath "PATH", "%", "z"
>>> when 3 then call SysFileSearch "%", "%", f., "z"
>>> when 4 then call SysFileTree "%", f., "z"
>>> when 5 then call SysFileTree "", f.
>>> otherwise exit
>>> end
>>> say "no SYNTAX"
>>> syntax:
>>> signal off syntax
>>> say condition("object")~code condition("object")~message
>>> i += 1
>>>
>>> m = ""~start("LENGTH")
>>> r = m~result
>>> signal start
>>> ~~~
>>>
>>> On Fri, Nov 20, 2020 at 1:08 PM Rick McGuire <object.r...@gmail.com>
>>> wrote:
>>>
>>>> I suspected it would. I'm not sure what's going on here. The destructor
>>>> for ApiContext in the ThrowException2 stub is supposed to release the
>>>> kernel semaphore when an exception is thrown, then when the exception is
>>>> caught in NativeActivation, the semaphore is reacquired. Somehow, the
>>>> semaphore is ending up as a nested request, such that the main thread ends
>>>> up holding on to it forever. I've traced this process in the debugger, and
>>>> everything is happening as suspected, but somehow the mutex is still messed
>>>> up. Does this fail on any other platforms, or is it just a Windows problem?
>>>>
>>>> Rick
>>>>
>>>> On Fri, Nov 20, 2020 at 5:58 AM Erich Steinböck <
>>>> erich.steinbo...@gmail.com> wrote:
>>>>
>>>>> Replacing ThrowException2 with RaiseException2 in
>>>>> nullStringException() in RexxUtilCommon.hpp makes this piece of code work
>>>>> again.
>>>>>
>>>>> On Fri, Nov 20, 2020 at 10:34 AM Erich Steinböck <
>>>>> erich.steinbo...@gmail.com> wrote:
>>>>>
>>>>>> isolate the problem to a single test
>>>>>>>
>>>>>> OK, this piece of code reproduces the hang - both on 32- and 64-bit
>>>>>> Windows
>>>>>>
>>>>>> ~~~
>>>>>> signal on syntax
>>>>>> call SysFileTree "", f.
>>>>>> syntax:
>>>>>>
>>>>>> m = ""~start("HELLO")
>>>>>> r = m~result
>>>>>> ~~~
>>>>>>
>>>>>> _______________________________________________
>>>>> Oorexx-devel mailing list
>>>>> Oorexx-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>>>
>>>> _______________________________________________
>>>> Oorexx-devel mailing list
>>>> Oorexx-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>>
>>> _______________________________________________
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>
>>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
