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@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