[boost] [serialization] Boost.Serialization 1.33.0 Breaks Serialization Code inDLLs

From: martin.ecker_at_[hidden]
Date: 2005-08-13 07:09:33

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