Le 7 mai 06, à 14:36, JOAQUIN LOPEZ MU?Z a écrit : Hello Joaquin and thank you very much for the very professional reply and patch. I am reporting complete success with your fix, both on my test case and on my real application. Not only my internal metadata does not get corrupted on reloading from serialized file anymore but the boost::archive::other_exception is also gone. I did test my application both with "cp -a /usr/share/doc" and uncompressing a linux tarball. The problem seems gone now.
This is a bug in B.MI, but it has nothing to do with const_mem_fun. Rather it lies in the serialization loading algorithm. I'd like you to make the following changes in your local copy of B.MI (I'm assuming you've got 1.33 as per what you say in the post):
1. Replace line 80 in boost/multi_index/detail/duplicates_iterator.hpp:
I have to admit that I did backport the fix to that bug already when I investigated reproducible crashes when serializing data to disk. After that the trusty Valgrind got me to line 76 of duplicates_iterator.hpp, some googling got me to the mailing list thread and to the patch. I will definitely recommend 1.34 as minimum version to build my project but until it is out, the admins will be required to manually patch the local boost installation.
2. Replace the beginning of rearranger() at line 1076 of boost/multi_index/ordered_index.hpp:
void rearranger(node_type* position,node_type *x) { node_type* before; if(!position){ ...
with the following:
void rearranger(node_type* position,node_type *x) { node_type* before; if(!position||comp(key(position->value),key(x->value))){ ...
3. Undo your previous hack which bypassed the archive_exception throw.
All done. As I said in the beggining of this message, I am reporting complete success. Joaquin, thank you so much! If your journeys ever bring you to the Azure coast of France, please come share a beer with me. I am staying subscribed to this mailing list which I feel welcoming. Sincerely, Julien Pervillé Intern, Global Core, Amadeus IT Group.