question to the pros: nasty ASSERTION in BOOST
-
Hy there! i have a hughe problem in my company. i have a quite complex application (distributed, corba, mulithreaded, Boost, QT 3.3) and after closing the program (int closeevent() pApp->exit()) the program closes but after ca 5 sec. there comes an ASSERTION attached_thread_count == 0 in tss_hooks.cpp the code in boost looks like that: attached_threadcount == 0 in tss_hooks.cpp. the code there looks like this: it is in on_process_exit().. catch( ... ) { boost::call_once(init_threadmon_mutex, once_init_threadmon_mutex); boost::mutex::scoped_lock lock(*threadmon_mutex); BOOST_ASSERT(attached_thread_count == 0); return -1; even with the help of some c++ gurus and DevPartnerStudio we could not find the problem. actually it isnt that annoying because only at exit it happens. but we cant deliver it to the customer like that. does enyone has an idea what to do against it, even a trick to just dont show the assertion? unfortunately i cant make a release-version for different reasons. ideas? suggestions?? thanx for any input!! p.s. someone gave me the following input in an other board: Anyway, the assertion comes from the thread_specific_ptr machinery. It means that something registered a thread-exit handler but it wasn't called. This might happen if, for example, you use a thread_specific_ptr from a thread that wasn't created with boost::threads. andreas
-
Hy there! i have a hughe problem in my company. i have a quite complex application (distributed, corba, mulithreaded, Boost, QT 3.3) and after closing the program (int closeevent() pApp->exit()) the program closes but after ca 5 sec. there comes an ASSERTION attached_thread_count == 0 in tss_hooks.cpp the code in boost looks like that: attached_threadcount == 0 in tss_hooks.cpp. the code there looks like this: it is in on_process_exit().. catch( ... ) { boost::call_once(init_threadmon_mutex, once_init_threadmon_mutex); boost::mutex::scoped_lock lock(*threadmon_mutex); BOOST_ASSERT(attached_thread_count == 0); return -1; even with the help of some c++ gurus and DevPartnerStudio we could not find the problem. actually it isnt that annoying because only at exit it happens. but we cant deliver it to the customer like that. does enyone has an idea what to do against it, even a trick to just dont show the assertion? unfortunately i cant make a release-version for different reasons. ideas? suggestions?? thanx for any input!! p.s. someone gave me the following input in an other board: Anyway, the assertion comes from the thread_specific_ptr machinery. It means that something registered a thread-exit handler but it wasn't called. This might happen if, for example, you use a thread_specific_ptr from a thread that wasn't created with boost::threads. andreas
The problem isn't the ASSERT but what thread is not terminated. It's the 1st priority to check which thread and what line in the thread is still busy when the exit signal has been fired. And why does it enter the
catchblock?! What throws?Maxwell Chen
-
Hy there! i have a hughe problem in my company. i have a quite complex application (distributed, corba, mulithreaded, Boost, QT 3.3) and after closing the program (int closeevent() pApp->exit()) the program closes but after ca 5 sec. there comes an ASSERTION attached_thread_count == 0 in tss_hooks.cpp the code in boost looks like that: attached_threadcount == 0 in tss_hooks.cpp. the code there looks like this: it is in on_process_exit().. catch( ... ) { boost::call_once(init_threadmon_mutex, once_init_threadmon_mutex); boost::mutex::scoped_lock lock(*threadmon_mutex); BOOST_ASSERT(attached_thread_count == 0); return -1; even with the help of some c++ gurus and DevPartnerStudio we could not find the problem. actually it isnt that annoying because only at exit it happens. but we cant deliver it to the customer like that. does enyone has an idea what to do against it, even a trick to just dont show the assertion? unfortunately i cant make a release-version for different reasons. ideas? suggestions?? thanx for any input!! p.s. someone gave me the following input in an other board: Anyway, the assertion comes from the thread_specific_ptr machinery. It means that something registered a thread-exit handler but it wasn't called. This might happen if, for example, you use a thread_specific_ptr from a thread that wasn't created with boost::threads. andreas