Re: [Oorexx-devel] [bugs:#1362] CALL ON ANY raises HALT too late and gives exception

[Rick M. <obj...@gm...>]

The HostEmu HI command just calls RexxSetHalt(), which should set a flag to
cause the current activation to check for external events between clause
executions. If the Halt flag is discovered, then it should perform normal
trap processing and queue a halt condition to be called after the next
clause is executed. The real work is done in the method
processClauseBoundary(). Just based on a quick look, I suspect the "&&" on
the last line of the method should be "||". It appears that the clause
boundary flag is getting set to false which is suppressing the check for
the pending condition.

Rick



On Mon, May 29, 2017 at 11:15 AM, Erich Steinböck <
eri...@gm...> wrote:

> I'm looking for help to better understand how to fix bugs:#1362
> <https://sourceforge.net/p/oorexx/bugs/1362/>, I'm printf-tracing some
> `Activity` and `RexxActivation` functions (see attached patch) for
> `signal/call on ERROR` and – for comparison – for `signal/call on HALT`
> with attached script.
>
> (In case you wonder, why I'm not using signal/call on ANY` as the bug
> description says: the issue seems to be related to the HALT condition, not
> being be specific to ANY)
>
>
> The trace for SIGNAL ON ERROR looks straight-forward:
> the condition is raised, it is confirmed it will be trapped, trap() is
> called and Rexx returns the expected message
>
> ~~~
> > TstBug1362-select signal error
> Activity::raiseCondition: will be trapped
> Activity::raiseCondition(DirectoryClass): calling trap()
> Activity::raiseCondition(DirectoryClass): calling trap()
> RexxActivation::run: catch (RexxActivation *t)
> RexxActivation::run: call processTraps()
> RexxActivation::processTraps(): entry
> RexxActivation::processTraps(): i=0
> COND: condition ERROR raised on line 17, desc 'exit 1', add 'The NIL
> object'
> ~~~
>
>
> Similar, the the trace for CALL ON ERROR shows
> the condition is raised, it is confirmed it will be trapped, trap() is
> called, and as this is a CALL (not SIGNAL) processing is delayed until
> ClauseBoundary; at ClauseBoundary the trap is processed, Rexx returns the
> expected message, and continues
>
> ~~~
> > TstBug1362-select call error
> Activity::raiseCondition: will be trapped
> Activity::raiseCondition(DirectoryClass): calling trap()
> Activity::raiseCondition(DirectoryClass): calling trap()
> RexxActivation::trap isCall -> clauseBoundary = true
> Activity::raiseCondition(DirectoryClass): (CALL ON - only) returning 1
> RexxActivation::processClauseBoundary: entry
> RexxActivation::processClauseBoundary: call processTraps()
> RexxActivation::processTraps(): entry
> RexxActivation::processTraps(): i=0
> COND: condition ERROR raised on line 17, desc 'exit 1', add 'The NIL
> object'
> RexxActivation::processClauseBoundary: conditionQueue->isEmpty 1
> returning
> ~~~
>
>
> The trace for SIGNAL ON HALT looks a little bit suspicious to me: HALT is
> detected (though initially no RaiseCondition() is called), and processing
> is delayed until ClauseBoundary (is that to be expected for SIGNAL)?
> Next, trapping is confirmed, but again, processing is delayed until
> ClauseBoundary (unexpected for me).  Upon next ClauseBoundary Rexx returns
> the expected message
>
> ~~~
> > TstBug1362-select signal halt
> Activity::halt: NULL
> RexxActivation::halt: clauseBoundary = true
> RexxActivation::processClauseBoundary: entry
> RexxActivation::processClauseBoundary: conditionQueue == OREF_NULL
> RexxActivation::processClauseBoundary: settings.haveHaltCondition()
> Activity::raiseCondition: will be trapped
> Activity::raiseCondition(DirectoryClass): calling trap()
> RexxActivation::trap HALT checking exit
> RexxActivation::run: catch (RexxActivation *t)
> RexxActivation::run: call processTraps()
> RexxActivation::processTraps(): entry
> RexxActivation::processTraps(): i=0
> RexxActivation::processClauseBoundary: entry
> RexxActivation::processClauseBoundary: conditionQueue->isEmpty 1
> COND: condition HALT raised on line 19, desc '', add 'The NIL object'
> ~~~
>
>
> The trace for CALL ON HALT shows that the trap is not executed at all.
> HALT is detected (though initially no RaiseCondition() is called),
> processing is delayed until ClauseBoundary, trapping is confirmed, but
> again, processing is delayed until ClauseBoundary (unexpected for me), and
> finally the expected action (Rexx message) is not taken.
>
> ~~~
> > TstBug1362-select call halt
> Activity::halt: NULL
> RexxActivation::halt: clauseBoundary = true
> RexxActivation::processClauseBoundary: entry
> RexxActivation::processClauseBoundary: conditionQueue == OREF_NULL
> RexxActivation::processClauseBoundary: settings.haveHaltCondition()
> Activity::raiseCondition: will be trapped
> Activity::raiseCondition(DirectoryClass): calling trap()
> RexxActivation::trap HALT checking exit
> RexxActivation::trap isCall -> clauseBoundary = true
> Activity::raiseCondition(DirectoryClass): (CALL ON - only) returning 1
> RexxActivation::processClauseBoundary: raiseCondition(HALT)
> returning
> ~~~
>
>
> What *is* the expected trace flow for the SIGNAL ON HALT and the CALL ON
> HALT path?  Are both paths broken?  Where do they go wrong?
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Oorexx-devel mailing list
> Oor...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>