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

Subject: [Boost-users] [Boost Serialization] crashing use case about serialization using pointers to objects of an abstract derived class using two DLLs
From: François Mauger (mauger_at_[hidden])
Date: 2011-06-13 05:12:44

Dear Boosters,

The use of Boost/Serialization through pointers  to objects  of an 
abstract derived  class across several DLLs has been addressed a couple 
of times so far in this list. Some very useful comments have been added 
in the doc by Robert, particularly concerning the "export/registration" 
mechanism. After investigation and careful reading of the docs and using 
some comments from this list, I now have what I consider as a minimal 
use case implementing:

- a DLL `A' with an abstract 'base' class and some inherited classes, 
all serializable.
- a DLL `B' with more inherited serializable class.

The purpose of this exercise is to demonstrate that it is possible
to pre-build serialization code across several DLLs and not only in the
executable unit (which is already known to work well). I really need 
such a system for my project(s) but it is clear from users' requests on 
the list that other people would like to benefit of such an approach.

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 ()
<<<

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 
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 hope some of you will find a little time to explore this use case
(the code is very simple) and will be able to propose a solution or at 
least some hint to fix this problem.

Thanks a lot.

Regards

frc
-- 
François Mauger
   Groupe "Interactions Fondamentales et Nature du Neutrino"
   NEMO-3/SuperNEMO Collaboration
LPC Caen-CNRS/IN2P3-UCBN-ENSICAEN
Département de Physique -- Université de Caen Basse-Normandie
Adresse/address:
   Laboratoire de Physique Corpusculaire de Caen (UMR 6534)
   ENSICAEN
   6, Boulevard du Marechal Juin
   14050 CAEN Cedex
   FRANCE
Courriel/e-mail: mauger_at_[hidden]
Tél./phone:      [phone]
Fax:             02 31 45 25 49 / ([phone]