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
