在 DLL 中使用时 Boost Spirit 崩溃
我在使用 Boost.Spirit 和 Boost.Thread 时遇到崩溃 我的应用程序中的库。 只有当我使用了圣灵时才会发生这种情况 解析器在进程的生命周期内从主线程开始。
崩溃发生在退出处，似乎与清理有关 由 Spirit 解析器分配的线程特定存储。 由于 DLL 的顺序，它可能会崩溃 卸载，因为线程特定内存是在 DLL 内分配的 已经被卸载了。 然而，直到应用程序本身退出后，Boost.Thread DLL 才会被卸载。
有没有办法让我强制 Spirit 清理它的特定线程 存储，例如当我收到进程分离通知时在我的 dll-main 中？
任何解决方案/提示将不胜感激。
附言！ 我的平台和设置：
- Visual Studio 2005
- BOOST_ALL_DYN_LINK
- BOOST_SPIRIT_THREADSAFE
I am experiencing a crash while using the Boost.Spirit and Boost.Thread
libraries in my application. This only happens if I have used the Spirit
parser during the lifetime of the process from the main thread.
The crash happens at exit and appears to be related to the clean-up of
thread specific storage allocated by the Spirit parser.
It is probably crashing due to the sequence of which DLLs are
unloaded, as the thread specific memory is allocated inside a DLL
that has already been unloaded. The Boost.Thread DLL is however not unloaded untill the application itself exits.
Is there a way for me to force Spirit to clean out its thread specific
storage, e.g. in my dll-main when i get a process-detach notification?
Any solutions/hints would be appreciated.
PS!
My platform and settings:
- Visual Studio 2005
- BOOST_ALL_DYN_LINK
- BOOST_SPIRIT_THREADSAFE
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好吧，我找到了一个解决方法。
在我使用 boost::spirit::parse 调用的每个地方，我基本上都会生成一个工作线程来运行它，而调用线程在与工作线程的连接调用上被阻塞。 并不理想，但到目前为止它似乎没有任何副作用。
仍然对任何替代方案感兴趣，因为我的直觉是不需要真正需要单独的线程。
Well I found a workaround.
Every place I use the boost::spirit::parse call, I basically spawn a workerthread to run it, while the calling thread is blocking on a join call with the workerthread. Not ideal, but it appears to be working without any sideeffects so far.
Still interested in any alternatives as my gut feeling is that a seperate thread shouldn't really be needed.
Boost.Spirit 是仅标头的，即它不驻留在自己的 dll 中，因此可能不是 dll 的卸载顺序，而是另一个问题。
确保包含您的 Spirit 解析器的实例已被删除并且不会留下悬空指针。
Boost.Spirit is header-only, i.e. it does not reside in its own dll, so maybe it is not the unloading order of dlls but rather a different issue.
Make sure the instance containing your spirit parser is deleted and doesn't leave dangling pointers.