Re: [Boost-users] [Boost Serialization] crashing use case about serialization using pointers to objects of an abstract derived class using two DLLs

Subject: Re: [Boost-users] [Boost Serialization] crashing use case about serialization using pointers to objects of an abstract derived class using two DLLs
From: Robert Ramey (ramey_at_[hidden])
Date: 2011-06-13 12:42:08

François Mauger wrote:
> Basically, the bits attached in the zip file work (under Linux/gcc,
> 4.X
> and Boost 1.44) BUT there is still one problem:
> one of the sample executable badly segfaults while terminating,
> probably
> at some singleton termination (however it is just a feeling).
>
> Here is a GDB dump:
>  >>>
>     from
> /scratch/sw/boost/install-1_44_0-Linux-i686-gcc45/lib/libboost_serialization.so.1.44.0
> #6  0x001aac6b in
> boost::serialization::void_cast_detail::void_caster_primitive<A::c1,
> A::base>::~void_caster_primitive() () from ./lib/libA.so
> #7  0x001aaced in
> boost::serialization::detail::singleton_wrapper<boost::serialization::void_cast_detail::void_caster_primitive<A::c1,
> A::base> >::~singleton_wrapper() () from ./lib/libA.so
> #8  0x00389e14 in __cxa_finalize () from /lib/i386-linux-gnu/libc.so.6
> #9  0x001a02b4 in __do_global_dtors_aux () from ./lib/libA.so
> #10 0x001adab0 in _fini () from ./lib/libA.so
> #11 0x0011ec3d in ?? () from /lib/ld-linux.so.2
> #12 0x00389a6f in ?? () from /lib/i386-linux-gnu/libc.so.6
> #13 0x00389acf in exit () from /lib/i386-linux-gnu/libc.so.6
> #14 0x00370e3f in __libc_start_main () from
> /lib/i386-linux-gnu/libc.so.6
> #15 0x08048b41 in _start ()
> <<<

We have recently made some some small changes which I believe
may address this.  The changes have been checked into the trunk
and release branches so should appear in 1.47.  It would be valueable
for you to test the most recent release version to see if I'm correct on 
this.

> The funny thing (however likely relevant) is that this program does
> NOT use serialization; it is just linked against DLLs with embedded
> serialization code. It encounters some kind of side-effect. All the
> executable that use serialization code from both DLLs work fine and we
> get the proper serialization/deserialization actions. Also this
> problem

Correct.  This is an effect of "registering" the derived types which
occurs whenever the DLL is loaded.  Since the process of loading
a DLL is the same regardless of whether the included functions are
called or not, this problem would still manifest itself.

> does not occur when the inheritance scheme of serializable class has
> only one level (see README in the zip file).
>
> As it is a rather complex problem which turns to be only demonstrated
> given a full multi-DLLs skeleton package, the attached ZIP provides
> all  the source code and a README file that explains how the DLLs are
> designed and used. There are build instructions and scripts too (for
> Linux).

I think we're ahead of you on this.  Turns out that this area is a minefield
which is much more subtle than it first appears.  On the upside, several
good people have taken an interest and progress is (slowly) being made.

Robert Ramey