C++ 延迟事件时，Boost元状态机会导致堆栈溢出

我有一些代码实现了基于boostmsm库的状态机。它一直工作得很好，直到我不得不添加一行延迟事件函子前端：

Row < StateX, Event1, none, Defer, none >

行

现在，每当这一行被命中时，线程就会以一个打击堆栈结束。我跟踪了MSM中的方法调用，不幸的是，一切似乎都按设计进行。以下是执行步骤：

使用Event1调用进程\u事件

Event1被添加到延迟函子内的延迟事件队列中

因为行已成功处理，所以handled设置为TRUE

在process_事件的末尾，有代码来处理无事件的转换。之所以需要这段代码，是因为如果事件导致从状态A移动到B，B可能会自动转换到另一个状态，而这是唯一可以处理这些状态的地方（在我的代码中，我没有使用任何这些，但逻辑仍然会被调用）

无事件\u帮助程序使用类型为“无”的事件调用进程\u事件

在处理“none”（无实际工作）时，代码现在看到队列中有一个延迟事件，因此它将其出列并再次调用process_事件

现在我们重复步骤1中的所有步骤，但我们仍然在上一步的函数中，所以这将继续进行，直到耗尽堆栈

延迟事件的逻辑似乎与处理无事件转换的逻辑发生了冲突，我很想进入boost代码并破解后面的代码。似乎，如果事件被“延迟”，则不应将其视为已处理，如果是这种情况，则不会触发无事件转换（因为它们不应触发），但状态机最终将在一个no_转换调用中结束，该调用本质上是一个捕获所有意外错误的处理程序。这还需要对库代码进行黑客攻击，我希望避免这种情况

但在我做任何事情之前，我想看看是否有其他人发现了这个。或者给我一些建议，告诉我在哪里可以得到帮助

更新：

---

显然，我公司使用的Boost库版本是1.44，该版本中存在延迟事件处理的bug。它在1.46.1中固定。

获得适当帮助的最佳位置是。Christophe对可能出现的bug报告的反应非常出色，但我不认为他这么看

---

或者，你可以直接给克里斯托夫发电子邮件，因为我知道他很乐意。我不会在这里发布他的电子邮件地址，但在gmane boost邮件列表档案中很容易找到。

获得适当帮助的最佳地点是。Christophe对可能出现的bug报告的反应非常出色，但我不认为他这么看

---

或者，你可以直接给克里斯托夫发电子邮件，因为我知道他很乐意。我不会在这里发布他的电子邮件地址，但很容易在gmane boost邮件列表档案中找到。

谢谢你的提示。我想我在某个地方读到过，虽然每个人都可以阅读boost邮件列表，但在上面发表文章只能通过邀请。你知道这是不是真的吗？我当时的印象是，我不能只是去那里随便问一个问题。@DXM:不，一点也不正确。如果你以前从未在ML上发表过文章，那么你的文章必须得到版主的批准，然后在几篇非垃圾邮件文章之后，你将被放在白名单上，提供自动批准。但是，在你被列入白名单之前，你只需等待主持人来处理，这通常是即时的，很少超过一两个小时。谢谢：）我有时会看一看，但不是经常看，所以在ML上发帖或给我发电子邮件会让你得到更快的答复（通常是一两天）。谢谢你的提示。我想我在某个地方读到过，虽然每个人都可以阅读boost邮件列表，但在上面发表文章只能通过邀请。你知道这是不是真的吗？我当时的印象是，我不能只是去那里随便问一个问题。@DXM:不，一点也不正确。如果你以前从未在ML上发表过文章，那么你的文章必须得到版主的批准，然后在几篇非垃圾邮件文章之后，你将被放在白名单上，提供自动批准。但是，在你被列入白名单之前，你只需等待主持人来处理，这通常是即时的，很少会超过一两个小时。谢谢：）我有时会看一看，但不是经常看，所以在ML上发帖或给我发电子邮件会让你得到更快的答复（通常是一两天）。是的，在1.44中有一个bug，正如您所发现的，它在1.46中得到了修复。如果由于某种原因您一直使用1.44，您可以通过在任何状态定义中添加以下内容来强制激活延迟事件，从而解决该错误：typedef mpl:：vector deferred_events；没错，在1.44中有一个bug，正如您所发现的，它在1.46中得到了修复。如果由于某种原因您一直使用1.44，您可以通过在任何状态定义中添加以下内容来强制激活延迟事件，从而解决该错误：typedef mpl:：vector deferred_events；