Opened 15 years ago
Closed 14 years ago
#1168 closed Bugs (worksforme)
[thread] tss crashes randomly
Reported by: | t_schwinger | Owned by: | Anthony Williams |
---|---|---|---|
Milestone: | To Be Determined | Component: | thread |
Version: | Boost 1.34.1 | Severity: | Problem |
Keywords: | thread tss | Cc: |
Description
Experienced with Mac OS 10.4.10 on an Intel-based Mac. The problem occurs with both 1.34 release and current trunk.
I had difficulties writing a minimalist program that reproduces the problem often enough to be catchable with a debugger.
The following gdb session illustrates the problem and was created executing the test 'trd_sp_singleton_threading' from the singleton archive in the vault http://tinyurl.com/35vlvb (a backport of Boost.FunctionTypes is needed to compile the test with 1.34 http://tinyurl.com/qaf5f - not needed with the trunk version):
Program exited normally. (gdb) r Starting program: /Users/tosh/Lab/boost_1_34_1/bin.v2/libs/utility/singleton/test/trd_sp_singleton_threading.test/darwin/debug/threading-multi/a.out No errors detected.
Program exited normally. (gdb) r Starting program: /Users/tosh/Lab/boost_1_34_1/bin.v2/libs/utility/singleton/test/trd_sp_singleton_threading.test/darwin/debug/threading-multi/a.out No errors detected.
Program exited normally. (gdb) r Starting program: /Users/tosh/Lab/boost_1_34_1/bin.v2/libs/utility/singleton/test/trd_sp_singleton_threading.test/darwin/debug/threading-multi/a.out
<snip ...>
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x448ca20d [Switching to process 734 thread 0x2103] 0x8fe12eb7 in dyldZN16ImageLoaderMachOC1EPKciPKhyyRK4statRKN11ImageLoader11LinkContextE () (gdb) bt #0 0x8fe12eb7 in dyldZN16ImageLoaderMachOC1EPKciPKhyyRK4statRKN11ImageLoader11LinkContextE () #1 0x0003724e in std::vector<void*, std::allocator<void*> >::insert (this=0x3004c0, position={_M_current = 0x0}, n=1, x=@0xb0203d9c) at /usr/include/c++/4.0.0/bits/stl_vector.h:658 #2 0x000372fd in std::vector<void*, std::allocator<void*> >::resize (this=0x3004c0, new_size=1, x=@0xb0203d9c) at /usr/include/c++/4.0.0/bits/stl_vector.h:427 #3 0x0003732a in std::vector<void*, std::allocator<void*> >::resize (this=0x3004c0, new_size=1) at /usr/include/c++/4.0.0/bits/stl_vector.h:442 #4 0x000339bc in boost::detail::tss::set (this=0x6264, value=0x3004a0) at ../../../../libs/thread/src/tss.cpp:231 #5 0x0000380b in boost::thread_specific_ptr<boost::thread_specific_singleton<X, 0>::instance_proxy::holder>::reset (this=0x6260, p=0x3004a0) at ../../../../boost/thread/tss.hpp:100 #6 0x000038b2 in boost::thread_specific_singleton<X, 0>::instance_proxy::get () at ../../../../boost/utility/thread_specific_singleton.hpp:100 #7 0x0000390d in boost::thread_specific_singleton<X, 0>::instance_proxy::operator-> (this=0x60e0) at ../../../../boost/utility/thread_specific_singleton.hpp:60 #8 0x00002699 in test1 () at trd_sp_singleton_threading.cpp:47 #9 0x00003c23 in boost::detail::function::void_function_invoker0<void (*)(), void>::invoke (function_ptr=@0xb0203f20) at ../../../../boost/function/function_template.hpp:114 #10 0x00034d45 in boost::function0<void, std::allocator<boost::function_base> >::operator() (this=0xb0203f1c) at ../../../../boost/function/function_template.hpp:692 #11 0x000325d0 in thread_proxy (param=0xbfffefa8) at ../../../../libs/thread/src/thread.cpp:108 #12 0x90024227 in _pthread_body () (gdb)
Attachments (1)
Change History (3)
by , 15 years ago
Attachment: | tss_bug.cpp added |
---|
comment:1 by , 15 years ago
Maybe related to #1154. No exact duplicate - also happens with statically linked program.
comment:2 by , 14 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
I can't duplicate the problem, but the TSS code has changed since 1.34.1, so it might have been fixed.
Attempt of minimal reconstruction of the problem. Could crash it in a batch loop - crash too unlikely for debugging