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 15:22:55

Guy Prémont wrote:
>> Guy Primont 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.
>
> I know that what I proposed is not a cure for the actual problem. But
> in my case, the application must work... ;)
>
> One way to implement the real fix would be to have a global
> repository of (i|o)serializer and pointer_(i|o)serializer for each
> archive type.

I've found no way to make a singleton which is global
across execution modules.

...

> Does .so in linux builds have the same problems? I haven't tried it,
> but I guess it does.

I'd be very, very surprised if it didn't.

>> 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).
>
>> From what I understand, the singleton creation for serialization of
>> a type
> (Node here) is a side effect of calling on serialization for that
> type.

more or less. actually it's a side-effect of exporting a type.

> Calling serialization of Node* will, in turn, create the singleton for
> pointer_iserializer. I don't think there is any other way of doing it.
> Adding an indirection level for the serializer, i.e. putting them in a
> repository, will avoid keeping track of several singletons for the
> same type that leads to conflicting behaviours.
>
>> 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.
>
> I haven't found the trap that you mentioned a few times. Could you
> give me a pointer to it? I'd like to enable it and see what it says
> in my application.

It's in (I think) basic_serializer_map.?pp).  It's commented out.

Robert Ramey