title: Boost Meta State Machine ends up with stack overflow when deferring an event
body: <p>I have some code that implements a state machine based on Boost MSM library. It's been working great until I had to add a row which defers an event functor front end:</p>
  
  <pre><code>Row &lt; StateX, Event1, none, Defer, none &gt;
  </code></pre>
  
  <p>Now whenever this row gets hit, the threads ends up with a blow stack.  I've tracked through method calls within MSM and unfortunately everything seems to work as designed.  These are the execution steps:</p>
  
  <ol>
  <li>process_event is invoked with Event1</li>
  <li>Event1 is added to deferred event queue inside Defer functor</li>
  <li>since the row is successfully processed, handled is set to TRUE</li>
  <li>at the end of process_event, there is code to process event-less transitions.  This code is needed because if an event causes move from state A to B, B might have automatic transitions to a different state and this is the only place those would get processed (in my code I'm not using any of these but the logic still gets invoked)</li>
  <li>eventless_helper invokes process_event with event of type "none"</li>
  <li>while processing "none" (no actual work), the code now sees that there's a deferred event in the queue, so it dequeues it and invokes process_event again.</li>
  <li>Now we repeat everything from step 1, but we are still inside function from the previous step, so this goes on until we exhaust the stack.</li>
  </ol>
  
  <p>It seems the logic for deferring events is getting into conflict with logic for processing event-less transitions and I'm very tempted to just go into boost code and hack out the latter ones.  It seems that if the event is "defered" it shouldn't be considered handled and if that was the case, event-less transitions wouldn't be fired (as they shouldn't), but then the state machine would end up in a no_transition call which is essentially a catch-all unexpected error handler. This would also require hacking into library code which I'd like to avoid.</p>
  
  <p>But before I do anything, I want to see if anyone else has found this. Or give me advice on where to get assistance with this.  </p>
  
  <p>UPDATE:
  Apparently Boost Library version my company was using was 1.44 and there was a bug with deferred event handling in that version.  It is fixed in 1.46.1.</p>