Re: [Boost-users] [Serialization] Inconsistent tracking_level whenswitching from static to DLL

Subject: Re: [Boost-users] [Serialization] Inconsistent tracking_level whenswitching from static to DLL
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-12-01 13:41:54

Guy Prémont wrote:
> Hi,
>
> I am using boost (1.40) serialization on Windows (VS 2008) to
> serialize a complex hierarchy of classes.
>
> My application is composed of different modules, each having its own
> serialization library. I have a Core library, with a
> CoreSerialization library, that defines a bunch of classes and base
> data types; I also have a Vehicle library, with a separate
> VehicleSerialization library, the defines some other classes with
> base classes in Core and that also use some user data types defined
> in Core. Using static libraries, everything saves and loads
> perfectly.
>
> We recently switched to using DLLs. When loading and saving with an
> application that only uses core (as Dlls) everything serializes
> perfectly. We can load files that were generated by an older
> application (using static libraries), save them and load them back.
>
> If the application also uses the Vehicle libraries, it can load older
> files (generated using  static libraries), save them, but fails to
> load them back.
>
> The difference between the files generated with a DLL application and
> a static link application, lies in the tracking of certain classes.
> Since the serialization is split between 2 DLLs, the tracking level
> (by default selectively) will actually depends on what classes are
> serialized in the DLL and may be different in different DLLs.
>
> This seems to be cause by the various singleton that are created,
> notably pointer_oserializer<T> and oserializer<T>. In a statically
> linked application, there is only one instance on those singleton, in
> a DLL linked application, there is one instance of the singleton for
> each DLL.  I've also noticed that in my Core DLL, for certain type,
> there are both notably pointer_oserializer<T> and oserializer<T>,
> while in the Vehicle DLL, there is only notably oserializer<T>, hence
> the difference in tracking level.
>
> There is an easy fix here, not to use selective tracking but track
> always or never, explicitly. But still, there seems to be some data
> that needs to  be shared across various serialization DLLs. I am a
> bit worry about some other bugs popping out relative to it.
>
> Has this bug ever been found? It may be a side effect of putting
> serialization code in DLLs, the documentation on that subject is a
> bit sparse.
>
> Thanks for any inputs

This is a result of the serialization library maybe being a little too
smart for it's own good.

The default behavior is to track if serialized as a pointer.  This
could vary if one invocation uses serialization of pointers and
other doesn't.  At one point I included code which would trap
when the serialization code for same type appeard in more than
one DLL.  This fixed the problem, but it required that users
organize their code so that serialization of a specific type be
included in one and only one DLL.  This turned out to be too
onerous a requirement so I had to comment out this check.

So, I'm going to guess that the safest thing is for such types is
to either turn tracking off or on rather than using the default.

Robert Ramey