2011/1/18 S Roderick <kiwi [dot] net [..] ...>

> On Jan 18, 2011, at 09:29 , Peter Soetens wrote:
>
> > On Wednesday 05 January 2011 10:15:58 Willy Lambert wrote:
> >> Hi all,
> >>
> >> I am using Orocos 1.10 and have a segfault when start a state machine in
> a
> >> [D] state (desactivating).
> >> The state machine is in this state because I desactivated it (and I
> think I
> >> stop it). I think it is in a [D] state because a command has blocked in
> the
> >> exit state.
> >>
> >> If I start it again Orocos end in segfault in StateMachine.cpp line 126
> >> (function "automatic") because of the "current' variable.
> >> I am sorry not being able to give more details about this, I am at a
> >> customer office with no easy web access (I am *not* requested an
> emergency
> >> answer).
> >>
> >> I think the problem which leads to this is in my app, but I think Orocos
> >> should not end in segfault.
> >
> > I could reproduce this as well with an error state. To know what the best
> fix
> > would be, I'm asking the users of these scripts what they do when
> > 1. the SM gets in the error state
> > OR
> > 2. a command of the SM hangs forever.
> >
> > Both situations boil down to the same (the current line refuses to
> execute or
> > complete). Since it's not documented what the behaviour should be, I
> prefer to
> > keep existing code working.
>
> +1
>
> > Do you:
> > 1. call stop() then deactivate() ?
> > 2. call deactivate() twice ?
> > 3. call stop() and try to start() again ?
> >
> > Which ones of these three are working now and should keep working ?
>
> This happens so seldom to us, as it is typically a development bug. Our
> working systems don't even deal with errors in state machines - we engineer
> our state machines to not error as much as we reasonably can. So overall, we
> don't care (in v1.10).
>

In my compagny (BA) we try to do the same as error cases a hard to manage.

What is more questionnable is how you reset a submachine into a main state
machine. Until now I didn't find the correct way to do it since you may have
blocking commands in ExitStates.

>
> > What we could do is:
> > 1. allow to deactivate (twice if necessary)
> > and
> > 2. allow to stop() (go to final state) and then reset() or start() or
> > deactivate()
>
> Having said that, whenever we get SM problems it's invariably during
> deactivation while shutting down. And that is more due to the deployer's
> inability to shutdown a system cleanly when the user asks to quit.
>
> I presume in 1) above that the second deactivate is a forceful one (ie
> ignores the error)? In 2), would this stop() also be forceful?
> S
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

On Tuesday 18 January 2011 15:35:05 S Roderick wrote:
> On Jan 18, 2011, at 09:29 , Peter Soetens wrote:
> > On Wednesday 05 January 2011 10:15:58 Willy Lambert wrote:
> >> Hi all,
> >>
> >> I am using Orocos 1.10 and have a segfault when start a state machine in
> >> a [D] state (desactivating).
> >> The state machine is in this state because I desactivated it (and I
> >> think I stop it). I think it is in a [D] state because a command has
> >> blocked in the exit state.
> >>
> >> If I start it again Orocos end in segfault in StateMachine.cpp line 126
> >> (function "automatic") because of the "current' variable.
> >> I am sorry not being able to give more details about this, I am at a
> >> customer office with no easy web access (I am *not* requested an
> >> emergency answer).
> >>
> >> I think the problem which leads to this is in my app, but I think Orocos
> >> should not end in segfault.
> >
> > I could reproduce this as well with an error state. To know what the best
> > fix would be, I'm asking the users of these scripts what they do when 1.
> > the SM gets in the error state
> > OR
> > 2. a command of the SM hangs forever.
> >
> > Both situations boil down to the same (the current line refuses to
> > execute or complete). Since it's not documented what the behaviour
> > should be, I prefer to keep existing code working.
>
> +1
>
> > Do you:
> > 1. call stop() then deactivate() ?
> > 2. call deactivate() twice ?
> > 3. call stop() and try to start() again ?
> >
> > Which ones of these three are working now and should keep working ?
>
> This happens so seldom to us, as it is typically a development bug. Our
> working systems don't even deal with errors in state machines - we
> engineer our state machines to not error as much as we reasonably can. So
> overall, we don't care (in v1.10).
>
> > What we could do is:
> > 1. allow to deactivate (twice if necessary)
> > and
> > 2. allow to stop() (go to final state) and then reset() or start() or
> > deactivate()
>
> Having said that, whenever we get SM problems it's invariably during
> deactivation while shutting down. And that is more due to the deployer's
> inability to shutdown a system cleanly when the user asks to quit.
>
> I presume in 1) above that the second deactivate is a forceful one (ie
> ignores the error)?

Yes.

> In 2), would this stop() also be forceful?

Yes. It would skip the current program body it's executing and try to call the
exit of current and entry of final state. If one of these fail as well, we're
back to square #1 and you could try to stop() again or to deactivate().

Peter