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

Subject: Re: [Boost-users] crash in boost serialization (1.44)
From: Guy Prémont (guy.premont_at_[hidden])
Date: 2010-12-14 15:10:29

> 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. Each
singleton, as it is created, could be registered into another singleton,
held by the serialization library. I think the key is to have a central and
unique access point for these objects, instead of relying on the compiler
creating singletons appropriately which in case of shared library does not
always produce the right result.

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

> 
> 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.
> >> Node table2;
> >> ...
> >> inputArchive >> table2;
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.

Thanks,
--
Guy Prémont, D.Sc.
Architecte logiciel senior / Senior software architect
CM Labs Simulations Inc. http://www.cm-labs.com/
Tel. [phone] ext