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
