anonymous — Thu, 28 Aug 2008 22:35:42 GMT

Replying to joerg.schmidt@methodpark.de:

Hi,

I'm using the serialization lib in my project. With the new 1.36 release, the app causes a segmentation violation on exiting. This didn't happen with the 1.35 release. Here's the debuggers' backtrace output:

#0 0xb56aa663 in std::_Rb_tree_rebalance_for_erase () from /usr/lib/libstdc++.so.6 #1 0xb54bad48 in boost::serialization::detail::extended_type_info_typeid_0::type_unregister () from /opt/project/lib/libboost_serialization-mt.so #2 0x083e381c in ~extended_type_info_typeid (this=0x8504ab8) at /opt/project/include/boost/serialization/extended_type_info_typeid.hpp:80 #3 0x08168a54 in tcf_801 () at /opt/project/include/boost/serialization/singleton.hpp:104 #4 0xb5521bcd in exit () from /lib/libc.so.6 #5 0xb550bfa4 in libc_start_main () from /lib/libc.so.6 #6 0x0815a261 in _start ()

I haven't time to investigate this at the moment. So I'm using 1.35 for now.

Best regards

Jörg

I think I have found and fixed an issue with the type_unregister and key_unregister functions. The problem seems to be with the removal of items from the multiset containing them. The items are inserted into the multiset via ptr and sorted on fields m_key or m_ti respectively. When the items are deleted from the multiset, a lower/upper bound search is performed to find the range of keys which contain the specified value (m_key, m_ti) and then subsequently the iterators on that range are subject to:

detail::ktmap::iterator start = x.lower_bound(this); detail::ktmap::iterator end = x.upper_bound(this); assert(start != end);

remove entry in map which corresponds to this type do{

if(this == *start){

x.erase(start); break;

}

}while(++start != end);

m_key = NULL;

Note that it breaks after removing the first item. It then sets the key to NULL. This means that on subsequent compares inside the set, if there are other instances of this key (which are held via ptr), the value of m_key is NULL. Inside the key_compare there are assert statements to check that m_key isn't NULL... after that all hell breaks lose :D.

The same pattern is in extended_type_info_typeid.cpp. I fixed my local copy by changing the loop to use:

do{

if(this == *start){

start = x.erase(start);

} else {

++start;

}

}while(start != end);

So all copies of an item with the same m_key or m_ti value are removed. After that everything seemed to run fine.

attachment set

Brandon Kohn — Thu, 28 Aug 2008 22:36:44 GMT

attachment → extended_type_info_files.patch

Patches for extended_type_info_typeid.cpp and extended_type_info.cpp

Fri, 29 Aug 2008 15:10:42 GMT

This is a duplicate of #2217

status changed; resolution set

Robert Ramey — Fri, 05 Sep 2008 22:42:09 GMT

status new → closed
resolution → fixed

I believe I have addressed a coding error in the unregistering of types as DLLs are or main programs are unloaded. I've checked the fix in the trunk. However, none of the test platforms have manifested this error, so it will by up to you test this when it migrates to the release branch.

Robert Ramey

Boost C++ Libraries: Ticket #2216: segementation fault in type_unregister()

attachment set

status changed; resolution set