Composite states with orthogonal regions of composite states behave strangely

[jefftrull]

When a composite state OrthoContainer containing two submachines A and B, each in an orthogonal region, is itself used in a composite machine, strange errors are observed:

1. initial anonymous transitions within the A and B submachines are not executed
2. if the OrthoContainer state is returned to, it is in an invalid terminal state.

Refer to this diagram:

If you construct the machine shown and process the ENTER_ORTHO event you will find that the A and B submachines are in their START states, despite there being an anonymous transition to MID in both cases.

If you follow this by processing the A::E event, you will find that both the A and B submachines move to the previously expected MID state, even though the START states have no event-based transitions.

If you then process B::E, ENTER_C, C::E, and ENTER_ORTHO to bring us back to the OrthoContainer state, you will find that the A state has correctly (for the first time) transitioned to MID, but the B state has for some reason terminated completely, ignoring the required B::E event.

I would be very grateful for a fix or workaround. Reproduction code matching the diagram is attached. Thank you.

ortho_bug_repro.cpp

[deoliveiravinicius]

I believe you are experiencing two separate issues:

• Anonymous transitions in a nested state are not being executed Anonymous transition in a nested state are not being executed unless on_entry event is declared in transition table #626.
  Workaround: declare on_entry event. Can use an empty action. e.g state + on_entry<>{}

This bug should have been fixed on version v1.1.12. What version do you use?

• Using a child state machine as the initial state of a composite state machine does not work. Leads to very unexpected results.
  a. Entering a previously visited composite of a compisite state re-enters its last active substate #495
  b. Problems with reentering a terminated substate. #440

Workaround: always use a dummy state as initial state and then transition to a sub-state machine. e.g: *"dummy_init"_s = state

[jefftrull]

This bug should have been fixed on version v1.1.12. What version do you use?

I have been using the master branch, and I can see that v1.1.12 was tagged in April, and yet BOOST_SML_VERSION remains on 1'1'11, which is odd. Checking out the v1.1.12 tag doesn't change my results. Is there something wrong with that release?

Regardless those two workarounds seem to have fixed my problem! Thank you so much.

[jefftrull]

Ah #644

[jefftrull]

Resolved by #648 and #649