boost/1.85.0: msm::front::state_machine infinite recursion segmentation fault

[hoyhoy]

boost::msm::back::state_machine is now going into an infinite recursion and crashing. Worked in boost/1.84.0.

Segmentation fault occurring on clang 18.1 and gcc 13.1, works on latest MSVC (17.9.6) though.

#101978 0x0000000000890a0c in boost::msm::back::state_machine<msm_front, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::handle_defer_helper<boost::msm::back::state_machine<msm_front, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>, int>::do_handle_deferred (this=0x7ffff309fcc0, new_seq=0x1) at include/boost/msm/back/state_machine.hpp:2028
#101979 0x0000000000890a0c in boost::msm::back::state_machine<msm_front, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::handle_defer_helper<boost::msm::back::state_machine<msm_front, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>, int>::do_handle_deferred (this=0x7ffff309fcc0, new_seq=0x1) at include/boost/msm/back/state_machine.hpp:2028
#101980 0x0000000000890a0c in boost::msm::back::state_machine<msm_front, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::handle_defer_helper<boost::msm::back::state_machine<msm_front, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>, int>::do_handle_deferred (this=0x7ffff309fcc0, new_seq=0x1) at include/boost/msm/back/state_machine.hpp:2028
#101981 0x0000000000890a0c in boost::msm::back::state_machine<msm_front, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::handle_defer_helper<boost::msm::back::state_machine<msm_front, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>, int>::do_handle_deferred (this=0x7ffff309fcc0, new_seq=0x1) at include/boost/msm/back/state_machine.hpp:2028
#101982 0x0000000000890a0c in boost::msm::back::state_machine<msm_front, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::handle_defer_helper<boost::msm::back::state_machine<msm_front, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>, int>::do_handle_deferred (this=0x7ffff309fcc0, new_seq=0x1) at include/boost/msm/back/state_machine.hpp:2028

[hoyhoy]

@ChristophStrehle there are breaking changes in boost/1.85.0. MSM now processes deferred events and the event table differently than boost/1.84.0. Both clang and gcc segmentation fault with our codebase written in 2017.

We have an event that is changing state and adding a deferred event and that caused an infinite loop. I just refactored our code to prevent the state change by deferring the second event rather than moving to the next state. The behavior of the msm changed between 1.84.0 and 1.85.0 for us.

Row < Running, Stop,    Stopped, Stop_cmd>
Row < Running, Close,   Internal, Stop_and_close>

If a Shutdown event occurs, our Stop_and_close defers a Close and processes a Stop, but then handle_defer_helper() causes another Stop_and_close which defers another Close which causes another deferred Stop_and_close to occur which is infinite recursion and a segmentation fault.

    template <class FSM,class SourceState,class TargetState>
    void operator()(Event::Close const& ev,FSM& fsm,
        SourceState& , TargetState& )
    {
        fsm.process_event( Event::Stop() );
        fsm.defer_event( ev );
    }

We should be in the Internal state after Close. It looks like a bug to me.

[ChristophStrehle]

Hello @hoyhoy, unfortunately I'm not so familiar with the implementation of the msm state machine. From the callstack and the description you provided I would guess that the change in behavior is caused by the commit f37d4a8 from @henry-ch.

[henry-ch]

Hello @hoyhoy,
could you provide me with a minimum example? It is possible that I induced a new bug while fixing one, it might also be possible that the fsm was wrong.

[hoyhoy]

Yeah, it's mega broken for us right now. Whatever was done post 1.83 seemed to break one of our applications.

Also, this started happening as well...
https://developercommunity.visualstudio.com/t/cl-193933523-x64-boost1840-boost/10622335

We can't compile on MSVC, and MSM no longer change states in the way all releases prior to Boost 1.85.0 used to.

I posted a minimum repro above. Basically, if you defer an event, Boost 1.85 changed how the state machine worked. The bug is, handle_defer_helper() is changing the next state when it didn't do that previously.

[henry-ch]

I cannot understand the problem with the above code. Sorry, "mega broken" is not helpful. Please provide a complete example with the whole state machine. Guessing is usually not a good idea.
I cannot reproduce the compiler crash with VS 17.8 (and Microsoft also not from what I see). Which compiler are you using?
Please provide also there a complete example, if possible, I will try to find the compiler you are using.