fast_pool_allocator crash

[philippeb8@…]

Hi,

I made some changes to the Block Pointer and now I am using a static pool and a static list of intervals that in turn is using the fast_pool_allocator. The destruction of the list with therefore be done and the end of the application, the problem is I experience a crash when the list is getting cleared at that moment. The application is located here: ​https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/block_ptr_test3.cpp

If I don't use the fast_pool_allocator then the bug goes away. The backtrace I get is:

#0 0x000000000042c51e in std::_List_base<boost::numeric::interval<long, boost::numeric::interval_lib::policies<boost::numeric::interval_lib::rounded_math<long>, boost::numeric::interval_lib::checking_strict<long> > >, boost::fast_pool_allocator<boost::numeric::interval<long, boost::numeric::interval_lib::policies<boost::numeric::interval_lib::rounded_math<long>, boost::numeric::interval_lib::checking_strict<long> > >, boost::default_user_allocator_new_delete, boost::details::pool::pthread_mutex, 32u, 0u> >::_M_clear (this=0x1d6a3ca0)

at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/list.tcc:76

#1 0x000000000042c579 in ~_List_base (this=0x1d6a3ca0)

at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_list.h:339

#2 0x000000000042c591 in ~list (this=0x1d6a3ca0)

at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_list.h:399

#3 0x000000000042c5bc in boost::thread_specific_ptr<std::list<boost::numeric::interval<long, boost::numeric::interval_lib::policies<boost::numeric::interval_lib::rounded_math<long>, boost::numeric::interval_lib::checking_strict<long> > >,boost::fast_pool_allocator<boost::numeric::interval<long, boost::numeric::interval_lib::policies<boost::numeric::interval_lib::rounded_math<long>, boost::numeric::interval_lib::checking_strict<long> > >, boost::default_user_allocator_new_delete, boost::details::pool::pthread_mutex, 32u, 0u> > >::delete_data::operator()

(this=0x1d69f300, data=0x1d6a3ca0)

at /home/vnmr1/phil/boost_1_46_1/boost/thread/tss.hpp:42

#4 0x00002abe08ee2d77 in boost::detail::set_tss_data ()

from /home/vnmr1/phil/lib/libboost_thread.so.1.46.1

#5 0x000000000042dd05 in ~thread_specific_ptr (this=0x681a80)

at /home/vnmr1/phil/boost_1_46_1/boost/thread/tss.hpp:79

#6 0x000000000040a744 in tcf_9 ()

at ../../../boost/detail/block_base.hpp:183

#7 0x0000003905e33355 in exit () from /lib64/libc.so.6 #8 0x0000003905e1d97b in libc_start_main () from /lib64/libc.so.6 #9 0x000000000040a2c9 in _start ()

Thanks, -Phil

[anonymous]

I've tracked the cause of this - it's because you have code using singleton_pool from a globally-scoped thread_specific_ptr. This then runs into order-of-destruction issues, with the global pool's destructor being called before that of the thread_specific_ptr's (which gets called very late due to the way it's implemented).

In general, this one's going to be very hard to fix, but I'll think about it ;-)

John.

[philippeb8@…]

I changed thread_specific_ptr to an auto_ptr and I still have the crash. There is a problem with the destruction order of fast_pool_allocator.

I changed my code to use a static thread_specific_ptr from within a static function and the crash went away because thread_specific_ptr gets detroyed before any of fast_pool_allocator's internal static objects (I imagine there are static objects inside fast_pool_allocator).

[John Maddock]

(In [73121]) Add some debugging code. Add tentative Valgrind support. Change singleton usage to address issue 5526 by making singletons eternal. Add Valgrind tests. Update docs to match. Refs #5526.

[John Maddock]

(In [73495]) Merge updated Pool lib from trunk. Fixes #1252. Fixes #2696. Fixes #4960. Fixes #5526. Fixes #5568. Fixes #5700.