boost::thread segfault
I am getting segmentation violations from inside of boost::thread Running valgrind, I get the following:
==31129== Thread 2: ==31129== Jump to the invalid address stated on the next line ==31129== at 0xEC834853E5894855: ??? ==31129== by 0x4A4DDE1: boost::function0<void, std::allocator<boost::function_base> >::function0(boost::function0<void, std::allocator<boost::function_base> > const&) (function_template.hpp:527) ==31129== by 0x4A4CF21: thread_proxy (thread.cpp:106) ==31129== by 0x31A0D06136: start_thread (in /lib64/tls/libpthread-2.3.4.so) ==31129== by 0x31A04C7532: clone (in /lib64/tls/libc-2.3.4.so) ==31129== Address 0xEC834853E5894855 is not stack'd, malloc'd or (recently) free'd ==31129== ==31129== Process terminating with default action of signal 11 (SIGSEGV) ==31129== Bad permissions for mapped region at address 0xEC834853E5894855 ==31129== at 0xEC834853E5894855: ??? ==31129== by 0x4A4DDE1: boost::function0<void, std::allocator<boost::function_base> >::function0(boost::function0<void, std::allocator<boost::function_base> > const&) (function_template.hpp:527) ==31129== by 0x4A4CF21: thread_proxy (thread.cpp:106) ==31129== by 0x31A0D06136: start_thread (in /lib64/tls/libpthread-2.3.4.so) ==31129== by 0x31A04C7532: clone (in /lib64/tls/libc-2.3.4.so)
It seems that when the new thread is created. Totalview shows that the thread dies in function_template.hpp at the line:
f.vtable->manager(f.functor, this->functor, boost::detail::function::clone_functor_tag)
Any thoughts on what could be causing this? I am using boost_1_34_0. I don¹t know if this is relevant, but I have a thread adaptor class that looks like:
class ThreadAdaptor { public: ThreadAdaptor( ExpressionBase& expr ) : expr_(expr) {} ThreadAdaptor(const ThreadAdaptor& ta) : expr_(ta.expr_) {} ~ThreadAdaptor(){} void operator()(){ expr_.evaluate(); } private: ThreadAdaptor& operator=(const ThreadAdaptor&); // no assignment ExpressionBase& expr_; };
Thanks for any advice, James
On Friday 25 January 2008 19:40, James Sutherland wrote:
Any thoughts on what could be causing this? I am using boost_1_34_0. I don¹t know if this is relevant, but I have a thread adaptor class that looks like:
class ThreadAdaptor { public: ThreadAdaptor( ExpressionBase& expr ) : expr_(expr) {} ThreadAdaptor(const ThreadAdaptor& ta) : expr_(ta.expr_) {} ~ThreadAdaptor(){} void operator()(){ expr_.evaluate(); } private: ThreadAdaptor& operator=(const ThreadAdaptor&); // no assignment ExpressionBase& expr_; };
If the "ExpressionBase" object is destroyed, that will also render this object unusable and crash any thread currently working on it, too, so you need to make sure that doesn't happen. Otherwise, can you provide a minimal compilable example? Lastly, your class above is superfluous: ExpressionBase x; boost::thread th( boost::bind( &ExpressionBase::evaluate, &x)); I.e. you use boost::bind to get a callable from a memberfunction. Note that passing 'x' into bind will also work but make a copy of it. You can prevent that using boost::ref() and boost::cref(). Uli
James Sutherland wrote:
I am getting segmentation violations from inside of boost::thread
Running valgrind, I get the following:
==31129== Thread 2: ==31129== Jump to the invalid address stated on the next line ==31129== at 0xEC834853E5894855: ??? ==31129== by 0x4A4DDE1: boost::function0<void, std::allocator<boost::function_base> >::function0(boost::function0<void, std::allocator<boost::function_base> > const&) (function_template.hpp:527) ==31129== by 0x4A4CF21: thread_proxy (thread.cpp:106) ==31129== by 0x31A0D06136: start_thread (in /lib64/tls/libpthread-2.3.4.so) ==31129== by 0x31A04C7532: clone (in /lib64/tls/libc-2.3.4.so)
Is this the "non-thread-safe-threads" bug? Have you upgraded your Boost.Function per the instructions at http://boost.org/ ? Are you creating several threads at nearly the same time? Does this only ever happen when the first few threads are created? What compiler are you using? Phil.
On 1/26/08 10:32 AM, "Phil Endecott" <spam_from_boost_dev@chezphil.org> wrote:
James Sutherland wrote:
I am getting segmentation violations from inside of boost::thread
Running valgrind, I get the following:
==31129== Thread 2: ==31129== Jump to the invalid address stated on the next line ==31129== at 0xEC834853E5894855: ??? ==31129== by 0x4A4DDE1: boost::function0<void, std::allocator<boost::function_base> >::function0(boost::function0<void, std::allocator<boost::function_base> > const&) (function_template.hpp:527) ==31129== by 0x4A4CF21: thread_proxy (thread.cpp:106) ==31129== by 0x31A0D06136: start_thread (in /lib64/tls/libpthread-2.3.4.so) ==31129== by 0x31A04C7532: clone (in /lib64/tls/libc-2.3.4.so)
Is this the "non-thread-safe-threads" bug? Have you upgraded your Boost.Function per the instructions at http://boost.org/ ? Are you creating several threads at nearly the same time? Does this only ever happen when the first few threads are created? What compiler are you using?
Phil.
I have not upgraded Boost.Function (I am running version 1.34.0). Is there a potential problem there that could be causing this? I am spawning several threads concurrently, but the segfault consistently occurs while creating the first thread. I am using gcc 3.4.6. I am not seeing this behavior on a simple problem, and haven't been able to reproduce it on a small enough problem to post source code for... James
James Sutherland wrote:
On 1/26/08 10:32 AM, "Phil Endecott" <spam_from_boost_dev@chezphil.org> wrote:
James Sutherland wrote:
I am getting segmentation violations from inside of boost::thread
Running valgrind, I get the following:
==31129== Thread 2: ==31129== Jump to the invalid address stated on the next line ==31129== at 0xEC834853E5894855: ??? ==31129== by 0x4A4DDE1: boost::function0<void, std::allocator<boost::function_base> >::function0(boost::function0<void, std::allocator<boost::function_base> > const&) (function_template.hpp:527) ==31129== by 0x4A4CF21: thread_proxy (thread.cpp:106) ==31129== by 0x31A0D06136: start_thread (in /lib64/tls/libpthread-2.3.4.so) ==31129== by 0x31A04C7532: clone (in /lib64/tls/libc-2.3.4.so)
Is this the "non-thread-safe-threads" bug? Have you upgraded your Boost.Function per the instructions at http://boost.org/ ? Are you creating several threads at nearly the same time? Does this only ever happen when the first few threads are created? What compiler are you using?
I have not upgraded Boost.Function (I am running version 1.34.0). Is there a potential problem there that could be causing this?
Yes, see http://boost.org/.
I am spawning several threads concurrently, but the segfault consistently occurs while creating the first thread. I am using gcc 3.4.6.
I'm guessing that gcc introduced its thread-safe statics feature sometime after 3.4.6, but I don't know that. I think this is consistent with the "non-thread-safe-threads" bug. Either upgrade your Boost.Function per the instructions at http://boost.org/, or use a newer g++ with thread-safe statics (it will probably have other improvements too), or wait for a boost release that includes this fix. Phil.
Is this the "non-thread-safe-threads" bug? Have you upgraded your Boost.Function per the instructions at http://boost.org/ ? Are you creating several threads at nearly the same time? Does this only ever happen when the first few threads are created? What compiler are you using?
Phil.
I have not upgraded Boost.Function (I am running version 1.34.0). Is there a potential problem there that could be causing this? I am spawning several threads concurrently, but the segfault consistently occurs while creating the first thread. I am using gcc 3.4.6.
I am not seeing this behavior on a simple problem, and haven't been able to reproduce it on a small enough problem to post source code for...
James
Updating to version 1.34.1 seems to have fixed the problem. Thanks for the tip. James
James Sutherland wrote:
I have not upgraded Boost.Function (I am running version 1.34.0). Is there a potential problem there that could be causing this? I am spawning several threads concurrently, but the segfault consistently occurs while creating the first thread. I am using gcc 3.4.6.
I am not seeing this behavior on a simple problem, and haven't been able to reproduce it on a small enough problem to post source code for...
James
Updating to version 1.34.1 seems to have fixed the problem. Thanks for the tip.
The Boost.Function thread-safety problem is NOT fixed in 1.34.1. Quote: Boost.Function in Boost 1.34.x has a bug that affects the construction of Boost.Function objects in a multi-threaded context. The problem has been fixed in the Boost trunk and for the upcoming Boost 1.35.x. So either you've got a different problem, or it is now masked. Phil.
participants (3)
-
James Sutherland -
Phil Endecott -
Ulrich Eckhardt