https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=740
Summary: calling resetError() is not enough to be allowed to
start() again
Product: RTT
Version: rtt-trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: Real-Time Toolkit (RTT)
AssignedTo: orocos-dev [..] ...
ReportedBy: sylvain [dot] joyeux [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0
The issue is the following: both fatal() and resetError() change the value of
mTaskState without actually touching the underlying activity.
Result: the task is in Stopped or PreOperational state after resetError() has
been called, but the activity is still running.
Proposed solution: there is no point having the activity running in fatal error
state, as the activity will not trigger anything anymore in this state.
Therefore, we could stop the activity if fatal() is called.
[Bug 740] calling resetError() is not enough to be allowed to st
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=740
Peter Soetens <peter [..] ...> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #2 from Peter Soetens <peter [..] ...> 2010-02-22 12:15:13 ---
(In reply to comment #1)
> Wrong analysis: the problem is not when fatal() is called in the updateHook(),
> because that case is properly handled in the ExecutionEngine code. The problem
> is if update() is called in other contexts, like in commands and methods.
>
> The fix is therefore to do what I proposed (have fatal() call engine()->stop())
> and remove the corresponding code in ExecutionEngine
I agree here, although I might be going somewhere else. I had a discussion with
Geoff Biggs about our state machine. We kindof agreed that:
1. Fatal error is non-recoverable, and entered by an 'unspecified' fatal error
condition reached in the RTT or a call to fatal() by user code.
A transition to the fatal error state is done by calling stopHook() (if
running) and then cleanupHook() (if configured). The ExecutionEngine is
stopped. There is no way out of this state.
2. Run-time error is recoverable, and entered when an exception is thrown in
updateHook(), or a call to error() by user code.
In the run-time error state errorHook() is executed, until 'recovered()' is
called by application code (enters running again), or stop() is called, which
leads to the stopped state. In case errorHook throws an exception, we go to
fatalError. This is about the only documented transition to enter fatalError.
A component in fatalError needs to be unloaded and reloaded if you want to make
it operational again.
Sounds like a fix ?
Peter
[Bug 740] calling resetError() is not enough to be allowed to st
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=740
--- Comment #1 from Sylvain Joyeux <sylvain [dot] joyeux [..] ...> 2009-12-01 11:12:52 ---
Wrong analysis: the problem is not when fatal() is called in the updateHook(),
because that case is properly handled in the ExecutionEngine code. The problem
is if update() is called in other contexts, like in commands and methods.
The fix is therefore to do what I proposed (have fatal() call engine()->stop())
and remove the corresponding code in ExecutionEngine