Hi, I'm having an assertion failed when trying to finish my application. I use Boost.Thread to create one thread and use serialization and spirit that I know use threads either. It wasnt happening when using an earlier boost cvs version... And for some reason I'm not being able to debug it, when trying to the app finishes when reaching the MSVC. I'm using MSVC 7.1 and the assertion is: File: boost-path\libs\thread\build\..\src\tss_hooks.cpp Line: 131 Expression: attached_thread_count == 0 This application uses different threads to create and destroy objects throughout its lifetime(probably even the static/singleton objects). It is an COM object and is accessed through "RPC", where the creation of the singletons takes place... If anybody has any clue to what it could be, I would really appreciate. I'm going to update my boost to the RC2 and see what happens. Thanks in advance, Felipe. -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
Hi, I'm having an assertion failed when trying to finish my application. I use Boost.Thread to create one thread and use serialization and spirit that I know use threads either. It wasnt happening when using an earlier boost cvs version... And for some reason I'm not being able to debug it, when trying to the app finishes when reaching the MSVC.
I'm using MSVC 7.1 and the assertion is:
File: boost-path\libs\thread\build\..\src\tss_hooks.cpp Line: 131
Expression: attached_thread_count == 0
This application uses different threads to create and destroy objects throughout its lifetime(probably even the static/singleton objects).
It is an COM object and is accessed through "RPC", where the creation of the singletons takes place...
Felipe, You will get this assertion whenever you use any Windows services that maintain a thread pool. COM/RPC is one of the examples. The problem is the threads from these pools are still around when main returns. I have not found out a way to control these threads. What I have done is to call on_thread_exit at the end of all my thread routines. In a way, this has rendenered automatic thread local storage cleanup on Windows useless(remember all those heated discussion about static boost::thread libraries?). HTH, Sean
On 8/11/05, Sean Huang <huangsean@hotmail.com> wrote:
Hi, I'm having an assertion failed when trying to finish my application. I use Boost.Thread to create one thread and use serialization and spirit that I know use threads either. It wasnt happening when using an earlier boost cvs version... And for some reason I'm not being able to debug it, when trying to the app finishes when reaching the MSVC.
I'm using MSVC 7.1 and the assertion is:
File: boost-path\libs\thread\build\..\src\tss_hooks.cpp Line: 131
Expression: attached_thread_count == 0
This application uses different threads to create and destroy objects throughout its lifetime(probably even the static/singleton objects).
It is an COM object and is accessed through "RPC", where the creation of the singletons takes place...
Felipe,
You will get this assertion whenever you use any Windows services that maintain a thread pool. COM/RPC is one of the examples. The problem is the threads from these pools are still around when main returns. I have not found out a way to control these threads. What I have done is to call on_thread_exit at the end of all my thread routines. In a way, this has rendenered automatic thread local storage cleanup on Windows useless(remember all those heated discussion about static boost::thread libraries?).
I've tried putting on_thread_exit on the end of each thread and still it gives me this assertion error... I'm starting to think I'll have to hack the thread sources to leak or something...I searched the docs for COM and didnt found anything about... Thanks for sharing your experience, Felipe.
HTH,
Sean _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
I've tried putting on_thread_exit on the end of each thread and still it gives me this assertion error... I'm starting to think I'll have to hack the thread sources to leak or something...I searched the docs for COM and didnt found anything about...
Thanks for sharing your experience, Felipe.
Have you made sure that all of your thread routines have returned before main returns (threads could still be running but your thread routine should finish)? Sean
I've tried putting on_thread_exit on the end of each thread and still it gives me this assertion error... I'm starting to think I'll have to hack the thread sources to leak or something...I searched the docs for COM and didnt found anything about...
One thing I forgot to mention is you also need to call on_thread_exit at the end of all COM method implementations that use boost::thread_specific_ptr because these methods run on RPC threads. Of course this essentially makes it behave like a scope variable. Sean
On 8/11/05, Sean Huang <huangsean@hotmail.com> wrote:
I've tried putting on_thread_exit on the end of each thread and still it gives me this assertion error... I'm starting to think I'll have to hack the thread sources to leak or something...I searched the docs for COM and didnt found anything about...
One thing I forgot to mention is you also need to call on_thread_exit at the end of all COM method implementations that use boost::thread_specific_ptr because these methods run on RPC threads. Of course this essentially makes it behave like a scope variable.
Is it possible that my destructors are bein called after on_thread_exit ? It is a static variable inside a function and I think the thread library should have been called in this variable constructor. Although I cant be sure..
Sean
Thanks -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
participants (2)
-
Felipe Magno de Almeida -
Sean Huang