Re: [Boost-users] [multi_index] const mem_fun serialization bug.
----- Mensaje original -----
De: Julien Pervillé
Hello boost-users.
I am writing to report an annoying serialization bug encountered while developing a project with Boost.multi_index, which is a wonderfully useful data structure. Thank you Joaquín!
First a fast overview of my project:
[...]
After hunting through the headers, I located the triggered exception to line 1080 of boost/multi_index/ordered_index.hpp (line number from boost 1.33)
Here is the context from the "rearranger" method where the exception is thrown:
1080 if(position!=x){
In Boost 1.33, tis is actually line 1088. Maybe a typo in your post? Anyway, I don't think this is important. [...]
I am looking forward to test patches and offer my help testing, so that this little quirk gets solved.
Hello Julien, thank you very much for using Boost.MultiIndex and for providing such a detailed bug report, with reproducible test case and all --actually, having the test case has made it easy to spot the problem. 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: if(pred(begin_chunk->value,node->value))advance(); with the following: if(node!=end&&pred(begin_chunk->value,node->value))advance(); This bug was previously spotted by Toby Smith, and it's currently fixed in the CVS version of B.MI, soon to be shipped with Boost 1.34. More details at: http://lists.boost.org/boost-users/2006/01/16710.php 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. That's it. I can confirm this makes seri-bug.cpp work OK. Could you please verify whether it also solves the problems in your real project? I'll devote some days to carefully study the issue and, if nothing weird shows, will commit the fix in the CVS HEAD and 1_33_4 branches next week. Please comment your results back. Thanks for reporting, best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
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.
Julien Pervillé ha escrito:
Le 7 mai 06, à 14:36, JOAQUIN LOPEZ MU?Z a écrit :
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
[...]
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.
I'd love to! La Riviera is one of the magical places in the world, long time I was last there (sigh). Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (3)
-
JOAQUIN LOPEZ MU?Z -
Joaquín Mª López Muñoz
-
Julien Pervillé