...

There is no reason for your snippet to fail. I have tested on openSUSE 11.3, 64 bits with gcc 4.5.0 and libboost_thread 1.42. Try to remove from the thread starter function the call to pthread_exit() and see if you still get the error.

It works well without pthread_exit(), I'm using boost about an year on this machine unchanged, that's why this fault wonder me sooo much.

update to the issue: the prog freezes with latest boost release 1.45 in the main thread, the child thread exits without any error:

(LD_LIBRARY_PATH is set to /home/vsysolts/boost/boost_1_45_0/stage/lib)

#include <stdio.h> #include <boost/thread.hpp>

void tf() { printf("thread\n"); sleep(1); pthread_exit(NULL); }

int main() { printf("main entered\n"); boost::thread t(tf); t.join(); printf("main exiting"); return 0; }

vsysolts:~/test/boost_thread (0) > g++ -I/home/vsysolts/boost/boost_1_45_0 test2.cpp -L/home/vsysolts/boost/boost_1_45_0/stage/lib -lboost_thread && gdb a.out GNU gdb (GDB) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/vsysolts/test/boost_thread/a.out...done. (gdb) r Starting program: /home/vsysolts/test/boost_thread/a.out [Thread debugging using libthread_db enabled] main entered [New Thread 0x7ffff6cce950 (LWP 12763)] thread [Thread 0x7ffff6cce950 (LWP 12763) exited] ^C Program received signal SIGINT, Interrupt. 0x00007ffff6cd9d59 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007ffff6cd9d59 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007ffff7bd6184 in boost::thread::join() () from /home/vsysolts/boost/boost_1_45_0/stage/lib/libboost_thread.so.1.45.0 #2 0x0000000000402d45 in main ()

-- Slava

Hmm, looking into thread.cpp implementation of thread_proxy (callback function for pthread_create()) and boost::thread::join I do not see how this join implementation would work with any abnormal thread termination. In thread.cpp boost::thread::join waits the thread termination on line: local_thread_info->done_condition.wait(lock); The lock gets signaled only at end of thread_proxy(), which is reached only if the user thread routine does "return" or is interrupted with boost::thread means. pthread_exit(), as well as any other emergency termination does only stack unwinding (on most but not all systems), so done_condition is simply never signaled in these circumstances. To be correct the thread_proxy() should have installed cleanup routine with pthread_cleanup_push() and, to be sure, have an local object which destructor would signal done_condition as well, but I do not see it in boost::thread code. Bogdan, when you said, the test program works for you - did you means it does return with status 0? If so, I wonder, which way the execution goes in your thread_proxy implementation - can you please debug it a little if you have some time? To build debug version of boost you need to add "variant=debug" option to bjam. I tried the same test program on ubuntu 10.04 TLS with gcc 4.4.3 and boost 1.40 - the same result as with latest boost: it freezes in boost::thread::join() on condition.wait(). -- Slava