[Bug libstdc++/52604] mt allocator crashes on multi-threaded

["laurent.alfonsi at st dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604

--- Comment #6 from Laurent Aflonsi <laurent.alfonsi at st dot com> 2012-03-23 11:06:57 UTC ---
Sorry for the late answer (sickness). 

Well, In fact there are 2 things in the atexit list :
1) The destruction of the "list_type" global variable. Destructor is :
  "std::list<std::string, __gnu_cxx::__mt_alloc<std::string,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> > >::~list()"
  => This one is registered in atexit list by the
__static_initialization_and_destruction_0() because it is a global variable.

2) The destruction of the mt_allocator itself
  "(anonymous namespace)::__freelist::~__freelist()"
  => This one is registered in atexit list during the main() execution. when
first using the mt_allocator (first called get_freelist())


The above 2 destructors are registered in atexit list in this order (1 then 2).
Then, they are invoked in the reverse order (2 then 1). The freelist is first
destroyed (where i proposed to add zeroing), followed by the destruction of the
list_type that invokes _M_get_thread_id() :

__gnu_cxx::__pool<true>::_M_get_thread_id ()
__gnu_cxx::__pool<true>::_M_reclaim_block ()
__gnu_cxx::__mt_alloc<std::_List_node<std::string>,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true>
>::deallocate(std::_List_node<std::string>*, unsigned long) ()
std::_List_base<std::string, __gnu_cxx::__mt_alloc<std::string,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >
>::_M_put_node(std::_List_node<std::string>*) ()
std::_List_base<std::string, __gnu_cxx::__mt_alloc<std::string,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> > >::_M_clear() ()
std::_List_base<std::string, __gnu_cxx::__mt_alloc<std::string,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> > >::~_List_base() ()
std::list<std::string, __gnu_cxx::__mt_alloc<std::string,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> > >::~list() ()
exit ()

Jakub, do you think this order of destruction is not justified ? Do you see
another solution than the one i proposed ?

Thanks very much.
Laurent