Hi, I am trying to serialize a multi-indexed container defined as below ( I am using boost 1.33.1 ): ____________________________________________________________________________ ___ /** Shorter id of namespaces. */ namespace bmi = boost::multi_index; /** Tags for accessing several indices defined below */ struct name_tag {}; class string_node { public: std::string m_name; friend class boost::serialization::access; void serialize ( boost::archive::polymorphic_iarchive & ar, const unsigned int file_version); void serialize ( boost::archive::polymorphic_oarchive & ar, const unsigned int file_version); }; /** Container of children of a node in the string tree */ typedef boost::multi_index_container< string_node*, bmi::indexed_by< bmi::sequenced<>, // sequenced type bmi::ordered_non_unique< bmi::tag<name_tag>, BOOST_MULTI_INDEX_MEMBER( string_node, const std::string, m_name)> > > node_set; ____________________________________________________________________________ ___ While serializing this container containing ===> several nodes with the same key <===, I get an access violation exception somewhere deep in the multi_index library. Tracing a little bit back the stack I noticed something unusual in boost_1_33_1\install\include\boost\multi_index\detail\duplicates_iterator.hp p in the duplicates_iterator::sync() member function (around line 80): ____________________________________________________________________________ ___ void sync() { if(pred(begin_chunk->value,node->value))advance(); } ____________________________________________________________________________ ___ This function seems to advance the iterator within a chunk of equal keys. However, the if clause does not consider the case where node == end. These are exactly the circumstances under which my program crashes in 'pred(begin_chunk...)'. Changing the if condition into ____________________________________________________________________________ ___ void sync() { if( (node != end) && pred(begin_chunk->value,node->value)) advance(); } ____________________________________________________________________________ ___ seems to fix the problem. However, I am not familiar with the overall implementation and therefore I cannot tell whether this is indeed the cause or whether there are side-effects to my patch. Has anyone else experienced a situation similar to this one? Is there something wrong with my container definition, to begin with? I really appreciate any feedback. Thanks, Bogdan