Re: [Boost-users] crash in boost serialization (1.44)

Subject: Re: [Boost-users] crash in boost serialization (1.44)
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-12-14 14:12:53

Guy Prémont wrote:
>> Robert Ramey <ramey <at> rrsd.com> writes:
>>>
>>> And you still have the crash? - maybe I'm wrong about the cause.
>>> Or maybe my advice doesn't go far enough.
>>>
>>> using something like
>>>
>>> ar << x // where x is an type mytype *
>>>
>>> in the mainline while the dll contains similar code might
>>> also create problems.  I'd have to think about this some more?
>>>
>>> Robert Ramey
>>
>> Yes, I still have the crash.
>>
>> I have a very small sample solution that causes the crash. I have
>> only one Dll
>> containing one interface (INode) and one concrete class (Node). The
>> Node
>> contains a list of INode*. If I call the serialization of one Node
>> (as an
>> object) from the main program, it crashes.
>>
>> (1)---
>> Node table;
>> ...
>> outputArchive << (const Node&)table;
>> Node table2;
>> ...
>> inputArchive >> table2; // crashes
>> ---
>>
>> If the main program contains the serialization of a Node* too, it
>> works.
>>
>> (2)---
>> Node* pTable = ...;
>> ...
>> outputArchive << pTable ;
>> Node* pTable2;
>> ...
>> inputArchive >> pTable2; // the code (1) works without a crash now
>> ---
>>
>
> It is exactly the setup I have and it also produces the crash. The
> way I understand what is happening, it is the invocation of
> serialization in the main program that causes singleton to be
> instantiated in the main executable, in addition to those in the DLL.
> Even though the actual serialization code is only the DLL. The fix I
> did in basic_iarchive::register_type, posted previously, prevents the
> overriding of an existing pointer_iserializer by a NULL. It is
> somewhat hacky as it does not address the cause of the problem, but
> it is an effective fix.

We've got different problems.  You're interested in getting your application
to work, while my concern is getting to the root of the problem.  If I add
your "fix" without really knowing is going on, I end up hiding the problem
which will only show up again in a form even harder to discover.

In this particular example, I want to know why the singleton is geting
created in the main line if there is no serialization code there.  When I
see this, I can suggest a fix for the user, but more importantly perhaps
figure out a way to trap this compile time with a static_error or
static_warning. If  I can't do that, it will give me another reason to
enable the trapping at runtime. (with user option to override).

> There is an implicit assumption that serialization code that is in a
> DLL will only be invoked by code that DLL.

not quite.  There is an implicit requirement that serialization code
be defined in only one place.

> I think it is too limitating,

I agree that it is limitiing.  But that's not the same as being a bad idea.

It's limiting to inhibit linkage to both static and dynamic runtime 
libraries
but doing so is a bad idea.  So trapping and prohibiting this behavior
makes one's programs more robust.  That is, not everything that might
be doable is a good idea to do.

>  maybe some other symbols need to be exported, beside void
T::serialize().

I've looked at this in some detail, and I don't think that there is a simple
universal fix which won't break some user programs in a way
which is impossible to track down.

To summarize, I want to trap this behavior.  I realize that this breaks
a lot of programs using DLLS.  I would argue that they are likely
broken anyway (at a minimum they suffer from code bloat).  But
I also recognise that overriding this trap is the most expedient
solution in many cases.

Robert Ramey

Robert Ramey