Hi, Thank you Robert for the fast reply and the hint. I've just checkout the trunk and built it. Now I link against 1.47 and my use case ran without apparent problem. Of course it needs more tests to validate a production approach for my DLLs but it is very encouraging after weeks/months of struggle to setup this multi DLL approach. It seems the code that you have modified/fixed is the 'void_caster::recursive_unregister()' method in 'void_cast.cpp' where there was some possibly double deletion occurence, depending on how the set was filled. If I copy the fix in the 1.44 source, is it supposed to work, or is there other stuff to be modified ? frc --
On 13/06/2011 18:42, Robert Ramey wrote: 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
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- 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@lpccaen.in2p3.fr Tél./phone: 02 31 45 25 12 / (+33) 2 31 45 25 12 Fax: 02 31 45 25 49 / (+33) 2 31 45 25 49