views:

367

answers:

2

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
+1  A: 

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.

Spirit itself is a template "lib" so you are correct it doesn't reside in its own DLL. It is however begin used (and thus the templates instantiated) inside one of my DLLs. Looks like the dangling pointer is actually generated by Spirit itself to me.
Morten Fjeldstad
+3  A: 

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.

Morten Fjeldstad
Have you found any bug report on that issue?
EFraim
I have not. But I haven't been keeping track of this problem either since I found this workaround.
Morten Fjeldstad