When terminating child FSMs, restart iteration after every child, to make
sure that we don't terminate a child twice. Terminating one child may emit
events that in turn terminates other children.
I created this patch because at first it looked like the cause of a bug,
which turned out not to be the case. So I have no actual use case of this
situation, but it does generally make sense to me, so submitting this.
Change-Id: I00990b47e42eeb43707a9a42abcd9df52fe5f483
Since removing an FSM from its parent twice causes a segfault, it is very
interesting to see when that is attempted.
Removing could be made more robust, but logging is interesting for
investigating why an FSM is being removed twice in the first place (currently
the case in openbsc's vlr_lu_fsm).
Change-Id: Idec6b7aa5344f1e903c9d2aa2a3640cab0d70fb0
When looking at log output, it is not interesting to see that a state
transition's petty details are implemented in fsm.c. Rather log the *caller's*
source file and line that caused an event, state change and cascading events.
To that end, introduce LOGPSRC() absorbing the guts of LOGP(), to be able to
explicitly pass the source file and line information.
Prepend an underscore to the function names of osmo_fsm_inst_state_chg(),
osmo_fsm_inst_dispatch() and osmo_fsm_inst_term(), and add file and line
arguments to them. Provide the previous names as macros that insert the
caller's __BASE_FILE__ and __LINE__ constants for the new arguments. Hence no
calling code needs to be changed.
In fsm.c, add LOGPFSMSRC to call LOGPSRC, and add LOGPFSMLSRC, and use them in
above _osmo_fsm_inst_* functions.
In addition, in _osmo_fsm_inst_term(), pass the caller's source file and line
on to nested event dispatches, so showing where a cascade originated from.
Change-Id: Iae72aba7bbf99e19dd584ccabea5867210650dcd
Provide one central LOGPFSML to print FSM information, take the FSM logging
subsystem from the FSM instance but use an explicitly provided log level
instead of the FSM's default level.
Use to replace some, essentially, duplications of the LOGPFSM macro.
In effect, the fsm_test's expected error changes, since the previous code dup
for logging events used round braces to indicate the fi's state, while the
central macro uses curly braces.
Change-Id: If295fdabb3f31a0fd9490d1e0df57794c75ae547
osmo_fsm_inst_alloc() logs allocation but osmo_fsm_inst_free() is
silent. Fix this by adding log message for deallocation to make FSM
lifecycle tracking easier. Also make sure it's covered by test suite.
Change-Id: I7e5b55a1fff8e36cf61c7fb61d3e79c1f00e29d2
In osmo_fsm_inst_state_chg(), we need to stop any not-yet-expired timer
of the old state before transitioning into the new state.
Change-Id: I2558f9a7027a877ea8263785ed3c8d70d2513996
The 'id' is used to generate the human-readable name of the FSM.
However, when the FSM creates slave FSMs later, the caller-passed "ID"
mgiht long be gone again (e.g. it was on stack memory). So let's copy
the 'id' string to a chunk of dynamically-allocated memory at time of
FSM start to ensure we have it later when creating child FSMs.
Change-Id: Ib88a2c02c5c91f17b4ec1e9db57a06d6d66465fb
If a FSM doesn't specify any timer_cb, simply terminate the FSM by
default on time-out. This is a reasonable default for most cases, and
avoids copy+pasting a one-line timer_cb function in every FSM.
Also, even if there is a timer_cb, let it have a return value to decide
if the core should terminate after return from timer_cb or not.
Change-Id: I0461a9593bfb729c82b7d1d1cf9f30b1079d0212
This code is supposed to formalize some of the state machine handling in
Osmocom code.
Change-Id: I0b0965a912598c1f6b84042a99fea9d522642466
Reviewed-on: https://gerrit.osmocom.org/163
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
Neels Hofmeyr
Max
Harald Welte