Re: [boost] [serialization] Boost.Serialization 1.33.0 BreaksSerialization Code inDLLs

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-13 10:48:48

As usual a very complete analysis from martin ecker.  Its amazing to me that 
you can understand things at this level of detail.

I had concluded that there would never be more than one instance of a 
extended_type_info object created for the same type.  So it would be more 
efficient to just compare the addresses.  Now I see (I think) how this 
assumption can be wrong.  I don't see an easier fix than putting back the 
old code.

I would like to add a couple of new tests to test this kind of thing.  You 
don't have anything suitable for this do you?

Robert Ramey

martin.ecker_at_[hidden] wrote:
> Hello,
>
> Boost.Serialization 1.33.0 breaks serialization of derived classes
> referenced via base class pointers when using DLLs on Windows and VC
> 7.1. It might also affect shared objects on Unix, but I'm not sure how
> the various Unix loaders handle multiple instances of the same
> template member function in multiple shared objects.
>
> In particular what happens is that objects that are serialized via a
> base class pointer are no longer deserialized correctly when
> deserialized in an application that uses the DLL (and not within the
> DLL itself). Instead they are deserialized as NULL pointers.
>
> The problem is that the virtual equal_to and not_equal_to member
> functions were removed from the extended_type_info base class. These
> functions were previously used by extended_type_info::operator == and
> extended_type_info::operator !=. Now operator == simply performs an
> equal check on the address of the extended_type_info object, whereas
> the previous version that used equal_to actually did a full compare of
> the stored type info keys.
>
> If DLLs are used and the DLLs themselves contain serialization code
> and BOOST_CLASS_EXPORT macros, this will fail because the
> extended_type_info objects are always static objects allocated on the
> stack of a member template function, e.g. in
> extended_type_info_typeid_1::get_instance.
>
> In a DLL situation this will cause multiple DLLs that include the
> header file with that template function to have multiple (i.e.
> separate) copies of that extended_type_info object. Thus, comparing
> them only via their addresses leads to disaster.
>
> The fix is easy. Simply put the old code for
> extended_type_info::operator ==
> and extended_type_info::operator != back in.
>
> Note that I haven't looked any further if there were other changes
> made to the code that also rely on the addresses of equal
> extended_type_info objects to be the same. This will also break
> serialization code in DLLs. I can only say that after I put the old
> code back in, our system could deserialize its data properly again.
>
> Best Regards,
> Martin
>
> TAB Austria
> Haiderstraße 40
> 4052 Ansfelden
> Austria
> Phone: [phone]
> Fax: [phone]
> E-mail: martin.ecker_at_[hidden]
> http://www.tab.at
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost