Re: [Boost-bugs] [Boost C++ Libraries] #2216: segementation fault in type_unregister()

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #2216: segementation fault in type_unregister()
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2008-08-28 22:35:43

#2216: segementation fault in type_unregister()
------------------------------------------+---------------------------------
  Reporter:  joerg.schmidt_at_[hidden]  |       Owner:  ramey        
      Type:  Bugs                         |      Status:  new          
 Milestone:  Boost 1.36.0                 |   Component:  serialization
   Version:  Boost 1.36.0                 |    Severity:  Problem      
Resolution:                               |    Keywords:               
------------------------------------------+---------------------------------

Comment(by anonymous):

 Replying to [ticket:2216 joerg.schmidt_at_[hidden]]:
 > 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.

-- 
Ticket URL: <http://svn.boost.org/trac/boost/ticket/2216#comment:1>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.