Re: [Boost-users] pthread_exit() from boost::thread segfaults
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.
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
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
#include 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
Viatcheslav.Sysoltsev wrote: ...
void tf() { printf("thread\n"); sleep(1); pthread_exit(NULL); }
pthread_exit in glibc/NPTL causes a "forced unwind" that is almost like a C++ exception, but not quite. (And its semantics probably have changed since last I looked.) Either way, a catch(...) clause that calls terminate(), as in the earlier version of Boost, or no catch clause at all, as in the later ones, should cause exactly the behavior you describe. Moving the cleanup code into a destructor should work on Linux. It won't on Mac OS X, for example, where pthread_exit unwinds without calling C++ destructors, as far as I know. But then you'd have other problems too. :-)
pthread_exit in glibc/NPTL causes a "forced unwind" that is almost like a C++ exception, but not quite. (And its semantics probably have changed since last I looked.) Either way, a catch(...) clause that calls terminate(), as in the earlier version of Boost, or no catch clause at all, as in the later ones, should cause exactly the behavior you describe. Moving the cleanup code into a destructor should work on Linux. It won't on Mac OS X, for example, where pthread_exit unwinds without calling C++ destructors, as far as I know. But then you'd have other problems too. :-)
You're absolutely right, the terminate() in catch(...) is the reason why I get in terminate() during pthread_exit(). I've wrongly thought one of my destructor throws during stack unwinding, but it turned out to be much simpler :( Well, I submitted bug report https://svn.boost.org/trac/boost/ticket/5013 about necessity to mention pthread_exit() incompability with boost::thread for boost <= 1.37 and https://svn.boost.org/trac/boost/ticket/5012 to fix the issue in svn trunk. Thank you all for participation :) -- Slava
participants (3)
-
Bogdan Cristea
-
Peter Dimov
-
Viatcheslav.Sysoltsev@h-d-gmbh.de