Robert Ramey wrote:
OK - I see the problem now - good work. I'm not sold on your
fix but I think this can be addressed.
I'll make the patch, test here, and check it into the trunk for testing.
OK thanks for the help. Having solved that one, I backported that patch to 1.36.0,
expanded my test cases, and we appear to have the same problems at exit with the
archive_pointer_oserializers:
archive_pointer_oserializer<Archive>::~archive_pointer_oserializer(){
// note: we need to check that the map still exists as we can't depend
// on static variables being constructed in a specific sequence
if(! serialization::singleton<
oserializer_map<Archive>
>::is_destroyed()
){
unsigned int count;
count = serialization::singleton<
oserializer_map<Archive>
>::get_mutable_instance().erase(this);
assert(count);
}
}
My stacktrace looks like:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb35276c0 (LWP 23136)]
0xb643d56b in std::_Rb_tree_rebalance_for_erase () from /usr/lib/libstdc++.so.6
(gdb) where
#0 0xb643d56b in std::_Rb_tree_rebalance_for_erase () from /usr/lib/libstdc++.so.6
#1 0xb6a8de2d in std::_Rb_tree, boost::archive::detail::type_info_pointer_compare, std::allocator >::erase (this=0xb62f6ec8, __position={_M_node = 0x83b5788})
at /usr/include/c++/4.2/bits/stl_tree.h:1247
#2 0xb6a8df14 in std::_Rb_tree, boost::archive::detail::type_info_pointer_compare, std::allocator >::erase (this=0xb62f6ec8, __first={_M_node = 0x83b5068}, __last=
{_M_node = 0x83b5068}) at /usr/include/c++/4.2/bits/stl_tree.h:1340
#3 0xb6a8df85 in std::_Rb_tree, boost::archive::detail::type_info_pointer_compare, std::allocator >::erase (this=0xb62f6ec8, __x=@0xbfc39bbc)
at /usr/include/c++/4.2/bits/stl_tree.h:1274
#4 0xb6a8dfc0 in std::set >::erase (this=0xb62f6ec8, __x=@0xbfc39bbc) at /usr/include/c++/4.2/bits/stl_set.h:373
#5 0xb62c7ce6 in ~archive_pointer_oserializer (this=0x82154ac)
at /opt/i3/ports/var/db/dports/build/file._opt_i3_ports_var_db_dports_sources_rsync.code.icecube.wisc.edu_icecube-tools-ports_devel_boost_1.36.0/work/boost_1.36.0/boost/archive/impl/archive_pointer_oserializer.ipp:74
#6 0x08120d23 in ~pointer_oserializer (this=0x82154ac) at /opt/i3/ports/include/boost-1.36.0/boost/archive/detail/oserializer.hpp:154
#7 0x0811d7f0 in __tcf_25 () at /opt/i3/ports/include/boost-1.36.0/boost/serialization/singleton.hpp:104
#8 0xb41e6084 in exit () from /lib/tls/i686/cmov/libc.so.6
#9 0xb41ce458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#10 0x080f4c01 in _start ()
This was part of the reason for the template approach I submitted... it looks like
lots of these singletons will have to be taken care of like this.
-t
