Re: [Boost-users] serialization 1.36.0 extended_type_infoexit issue(s)

Subject: Re: [Boost-users] serialization 1.36.0 extended_type_infoexit issue(s)
From: Robert Ramey (ramey_at_[hidden])
Date: 2008-10-08 17:11:53

troy d. straszheim wrote:
> Robert Mecklenburg, I'd be interested to see what you get from
> running your tests under valgrind like this:
>
>   valgrind --tool=memcheck --malloc-fill=FF --free-fill=EE
> ./my_failing_test
> Specifically
>
> - what happens while all the global statics are being destroyed
> - Can you get a test that passes when run 'normally' to fail when run
>   under valgrind as above?
>
> I've been chasing this for a few days and it just got away from me
> for the third or fourth time.  It looks like there are some
> double-deletes around and I wouldn't be surprised if it were a
> compiler or std library bug.  I can come up with one only one
> (lame) question so far...  why are the key_unregister methods
> of the extended_type_info classes written like this:
>
> 85 BOOST_SERIALIZATION_DECL(void)
> 86 extended_type_info::key_unregister() {
> 87     assert(NULL != m_key);
> 88     if(! singleton<detail::ktmap>::is_destroyed()){
> 89         detail::ktmap & x =
> singleton<detail::ktmap>::get_mutable_instance(); 90 
> detail::ktmap::iterator start = x.lower_bound(this); 91 
> detail::ktmap::iterator end = x.upper_bound(this); 92        assert(start 
> != end); 93
> 94         // remove entry in map which corresponds to this type
> 95         do{
> 96             if(this == *start)
> 97                 x.erase(start++);
> 98             else
> 99                     ++start;
> 100         }while(start != end);
> 101     }
> 102     m_key = NULL;
> 103 }
>
> instead of, say,
>
> 85 BOOST_SERIALIZATION_DECL(void)
> 86 extended_type_info::key_unregister() {
> 87     assert(NULL != m_key);
> 88     if(! singleton<detail::ktmap>::is_destroyed()){
> 89         detail::ktmap & x =
> singleton<detail::ktmap>::get_mutable_instance(); 97        x.erase(this); 
> 101     }
> 102     m_key = NULL;
> 103 }

It is possible for the same type to be in the registry more than once.
This can occur when code for a serializable type is loaded in a DLL.
When the DLL unloads, it takes its code with it.  So vtable displatch
won't work any more and will crash if used.  So its important to
remove the member which correponds to the exact extended_type_info
record being destroyed.  Erasing just one which matches the current
type is not enough.

Robert Ramey