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: François Mauger (mauger_at_[hidden])
Date: 2011-06-13 19:26:09

On 14/06/2011 01:37, Robert Ramey wrote:
> François Mauger wrote:
>> 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.
> Was all this effort related to boost serialization or all the
> "other" stuff which appears when one does this?

Well, I've used Boost/Serialization since 2007 in a small experimental 
physics project (however it implied ~TB of experimental data). I was 
really impressed by the elegance of its approach and implementation. 
Since 2010, I've tried to generalize the use of B/S in a larger software 
framework which implies a hierarchy of ~50 serializable classes spreaded 
across ~10 DLLs. Using 6 different archives (official text/xml/portable 
binary from Christian Pfligersdorffer + Nan/inf float support) and 
dozens of serializable classes, it turned out that we cannot go on with 
the 'single unit instantiation' approach. It is too expensive while 
compiling the executable, particularly during the development cycle when 
each minute means a rebuilt !
So making the multi-DLL precompiled serialization code is a must !
It really fastens the build and ease of our libs. It should now be 
possible to add serialization features to any class in a DLL, with a
suitable integration protocol in our framework.

So really yes I fought against boost serialization to use it in this 
way. I was quite desesperate because whatever way I used during the last 
months has led to broken execution at some points. At the very 
beginning, I must admit my errors and misunderstanding of some "golden 
rules" (export...). But at the end, even following strictly the "rules" 
were of no help to suppress the nasty (and last) effect I mentionned.

>> 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 ?
>>
>
> In this particular instance, it's just the changes in
> 'void_caster::recursive_unregister()'
>
> BTW, credit for fixing this incredible obscure and difficult
> to find bug goes to ...Aaron Barany.  I was stuck with this
> until he fixed it.

Had a look on the fix and it is clearly a very subtle effect, difficult 
to understand and track.
I think here we will have a toast for Aaron ASAP ! ;-)

Thanks again for your help and work.

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]