|
Boost Users : |
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: 02 31 45 25 12 / (+33) 2 31 45 25 12 Fax: 02 31 45 25 49 / (+33) 2 31 45 25 49
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net