Hi all (and particularly Boost/(De-)Serializer), I use Boost 1.44, gcc 4.4.1, Linux. The problem: I have two home made libraries compiled as DLL under linux: - 'datatools' provides the 'libdatatools.so' DLL - 'brio' provides the 'libbrio.so' DLL I use Boost serialization features for derived pointers. Below are the details: STEP 1: 'datatools' is the base library. It defines: - its own namespace: 'datatools' - a virtual class (interface) named 'i_serializable' from which all other serializable classes should inherit in order to benefit of the (de)serialization mechanism through pointer to this base class. [see http://www.boost.org/doc/libs/1_46_1/libs/serialization/doc/serialization.ht...] - some concrete classes (A, B, C) that inherit from the 'i_serializable' interface and register themselves using the export key features described in http://www.boost.org/doc/libs/1_46_1/libs/serialization/doc/special.html#exp... Typical inheritance diagram looks like: <pre> datatools::i_serializable | +--------------+--------------+ | | | datatools::A datatools::B datatools::C | datatools::A' </pre> Here is the typical model of the 'A.hpp' header file for the A class: <pre> ... #include // include Boost/Serialization text/XML/binary archives #include // include the abstract mother interface class ... namespace datatools { class A: public i_serializable { blah-blah.. // no inline code (from http://www.boost.org/doc/libs/1_46_1/libs/serialization/doc/special.html#dll...) template<class Archive> void serialize (Archive & ar, const unsigned int version); }; } // register the class with a specific GUID: BOOST_CLASS_EXPORT_KEY2 (datatools::A, "datatools::A"); </pre> Here is the model of the 'A.cpp' implementation file: <pre> namespace datatools { ... template<class Archive> void A::serialize (Archive & ar, const unsigned int version) { ar & boost::serialization::make_nvp( "datatools__serialization__i_serializable", boost::serialization::base_object

(*this) ); ar & more data (with NVP stuff)...; }

} // end of namespace datatools BOOST_CLASS_EXPORT_IMPLEMENT(datatools::A) // explicit instantiation for all kind of known archives: #include // include the known text/XML/binary archives template void datatools::A::serialize(boost::archive::text_oarchive & ar, const unsigned int version); template void datatools::A::serialize(boost::archive::text_iarchive & ar, const unsigned int version); template void datatools::A::serialize(boost::archive::xml_oarchive & ar, const unsigned int version); ... more... </pre> Finaly, I can compile all this stuff using gcc and build the 'libdatatools.so' library which I prepend to my LD_LIBRARY_PATH. Everything looks fine. A test program 'prg1.cpp' that links against only 'libdatatools.so' and 'libboost_serialization.so' works prefectly, serialiazing and deserialiazing any collection of pointers to A,B, or C classes without problem. A must ! Thanks to Robert for that magic ! At this point, everything looks (is?) fine. Note that I have followed (in principle) all the guidelines provided by Robert. STEP 2: Now let's consider the actual problem ! As said before, my 'datatools' library is the base of some modular project with some other libraries that depend on 'datatools' (and Boost/Serialization). The 'brio' library is such a beast: <pre> Boost/Serialization | datatools | brio </pre> It has its own namespace: 'brio' It provides a few other dedicated classes, inherited from the 'datatools::i_serializable' abstract class and which are serializable via Boost. Let's consider the serializable 'brio::D' class, designed on the model of 'datatools::A' and using the same implementation recommendations. I have followed the guidelines use for the 'datatools::A' class to write both 'D.hpp' and 'D.cpp' files. Now the inheritance scheme is: <pre> datatools::i_serializable : | : +--------------+--------------+------------+-----+- - - - | | | : | datatools::A datatools::B datatools::C : brio::D | : datatools::A' : libdatatools.so scope : libbrio.so scope : </pre> I can compile the 'libbrio.so' DLL without any problem. Now I want to run a sample program 'prg2.cpp' that performs some (de)serialization operations on a collection of pointers to 'datatools::A', 'datatools::B', 'datatools::C' AND 'brio::D' instances. This program is linked against the following libraries (among others): - libbrio.so - libdatatools.so - libboost_serialization.so Well, it compiles perfectly. Note this program links against third-party libraries too, among them some are explicitely using 'dlopen' and 'dlclose' to satisfy internal and critical features that are out of my scope. I have no idea if this can have side-effect. However, when I run it, I observed the following behaviour: - all (de)serialization operations are done properly and I get files with embeded (text/XML...) portable archives than can be reloaded without problem. - at the END of the program, while some cleaning code is invoked (some kind of deep buried code out of my skills and understanding), I get a Segmentation fault. Here is a dump of the GDB backtrace: <pre> Program received signal SIGSEGV, Segmentation fault. 0x02647c78 in boost::serialization::typeid_system::extended_type_info_typeid_0::is_less_than(boost::serialization::extended_type_info const&) const () from /scratch/sw/boost/install-1_44_0-Linux-i686-gcc44/lib/libboost_serialization.so.1.44.0 (gdb) bt #0 0x02647c78 in boost::serialization::typeid_system::extended_type_info_typeid_0::is_less_than(boost::serialization::extended_type_info const&) const () from /scratch/sw/boost/install-1_44_0-Linux-i686-gcc44/lib/libboost_serialization.so.1.44.0 #1 0x0264737b in boost::serialization::extended_type_info::operator<(boost::serialization::extended_type_info const&) const () from /scratch/sw/boost/install-1_44_0-Linux-i686-gcc44/lib/libboost_serialization.so.1.44.0 #2 0x0264dcac in boost::serialization::void_cast_detail::void_caster::operator<(boost::serialization::void_cast_detail::void_caster const&) const () from /scratch/sw/boost/install-1_44_0-Linux-i686-gcc44/lib/libboost_serialization.so.1.44.0 #3 0x0264e56d in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /scratch/sw/boost/install-1_44_0-Linux-i686-gcc44/lib/libboost_serialization.so.1.44.0 #4 0x0264ed8d in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /scratch/sw/boost/install-1_44_0-Linux-i686-gcc44/lib/libboost_serialization.so.1.44.0 #5 0x0264e5ee in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /scratch/sw/boost/install-1_44_0-Linux-i686-gcc44/lib/libboost_serialization.so.1.44.0 #6 0x024a6da7 in boost::serialization::void_cast_detail::void_caster_primitive::~void_caster_primitive() () from /home/mauger/Private/Work/lpc_nemo_svn/sw/datatools/datatools_trunk/Linux-i686/lib/libdatatools.so #7 0x024a6f04 in boost::serialization::detail::singleton_wrapper >::~singleton_wrapper() () from /home/mauger/Private/Work/lpc_nemo_svn/sw/datatools/datatools_trunk/Linux-i686/lib/libdatatools.so #8 0x0298c428 in __cxa_finalize (d=0x2609830) at cxa_finalize.c:56 #9 0x02426f04 in __do_global_dtors_aux () from /home/mauger/Private/Work/lpc_nemo_svn/sw/datatools/datatools_trunk/Linux-i686/lib/libdatatools.so #10 0x02534100 in _fini () from /home/mauger/Private/Work/lpc_nemo_svn/sw/datatools/datatools_trunk/Linux-i686/lib/libdatatools.so #11 0x0011dee6 in _dl_fini () at dl-fini.c:248 #12 0x0298c05f in __run_exit_handlers (status=0, listp=0x2a9e304, run_list_atexit=true) at exit.c:78 #13 0x0298c0cf in *__GI_exit (status=0) at exit.c:100 #14 0x02973b5e in __libc_start_main (main=0x8059495 <main>, argc=1, ubp_av=0xbfffcfd4, init=0x8061c40 <__libc_csu_init>, fini=0x8061c30 <__libc_csu_fini>, rtld_fini=0x11dcc0 <_dl_fini>, stack_end=0xbfffcfcc) at libc-start.c:252 #15 0x080592c1 in _start () at ../sysdeps/i386/elf/start.S:119 </pre> If one ignores the nasty details from this stack (local pathes and names), one observe that the problem seems to be related to some unregistration of some Boost/Serialization material. It occurs while the executable is trying to destruct some singleton_wrapper template class that manages some serializable classes from the 'datatools' library: - class 'datatools::test::more_data_t' (call it A') - and its mother class 'datatools::test::data_t', (call it A) inherited from 'datatools::i_serializable'. I expect such singleton is a static instance attached in some DLL. Am I wrong ? If not, which DLL is concerned 'libdatatools.so', 'libbrio.so' ? My feeling is that I have a problem with some arbitrary order of library unloading and messy unregistration that comes with. Unless there is a specific order to aggregate module within in DLL (A.o B.o A'.o...). Unfortunately, my skills are too limited to make a better idea and find a solution. There is some comments by Robert concerning such possible problems, but I'm not sure it makes sense in my case. So I will really appreciate if someone could advise me and possibly give me some hints. Thanks a lot for attention and help. Apologize for this rather long and technical issue. 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@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