"Enrico Carrara" <enrico.ecamail@gmail.com> wrote in message news:ca17d0c90906080012k61174cc5wec021603e71cb65c@mail.gmail.com...On Fri, Jun 5, 2009 at 7:34 PM, Robert Ramey <ramey@rrsd.com> wrote:
I believe I've fixed this at least on my machine and perhaps on the trunk. I'm tracking down a couple of other bugs but I don't know that I'll be able to get all these fixes tested and checked in by the 15 June deadline for 1.40Thank you for your prompt answer, I am sincerely honored by having it.As far as I understand, the fix is in recursive_unregister:BOOST_SERIALIZATION_DECL(void)
void_caster::recursive_unregister() const {
if(void_caster_registry::is_destroyed())
return;void_cast_detail::set_type & s
= void_caster_registry::get_mutable_instance();// delete all implied void_casts.
void_cast_detail::set_type::iterator it;
for(it = s.begin(); it != s.end(); ++it){
if((*it)->is_shortcut()){
if(m_derived == (*it)->m_base
|| (*it)->m_derived == m_base){
s.erase(it); // <<< HERE <<<
delete *it;
it = s.begin();
}
}
}I am under the impression that after s.erase(it) the iterator
might be invalid and dereferencing it in the following statement
might lead to undefined behaviour. Actually an error is given
when I compile and run it on VC2005 (only tried debug conf).What do you think of the following variant:...
if(m_derived == (*it)->m_base
|| (*it)->m_derived == m_base){
void_cast_detail::set_type::value_type v = *it;
s.erase(it);
delete v;
it = s.begin();
}
...It seems safer to me and eliminates the error.Thank you in advance for any possible further advice on the subject.Regards,
eca
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users