[Serialization] Stack Overflow on exit in 1.39.0: patch possibly available?
Hello, As others did (see http://lists.boost.org/boost-users/2009/05/48047.php), I had the problem of stack overflow on program exit while using BOOST_CLASS_EXPORT with version 1.39.0, probably due to an error in void_caster.cpp. Is it possible to have a patch for it before delivery of next version and how? Thanks in advance, eca
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.40 Robert Ramey "Enrico Carrara" <enrico.ecamail@gmail.com> wrote in message news:ca17d0c90906050216u4d7d4be2qa44f8cc50a0c779a@mail.gmail.com... Hello, As others did (see http://lists.boost.org/boost-users/2009/05/48047.php), I had the problem of stack overflow on program exit while using BOOST_CLASS_EXPORT with version 1.39.0, probably due to an error in void_caster.cpp. Is it possible to have a patch for it before delivery of next version and how? Thanks in advance, eca ------------------------------------------------------------------------------ _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Robert Ramey 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.40
Hi Robert, Would you mind specifying what these bugs are in Trac so I can follow? I also ran into the void_caster.cpp issue and patched Boost locally. Thanks. -- Sohail Somani http://uint32t.blogspot.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.40
Thank 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
Very astute obvservation. I've made a(nother) change. Hopefull this will migrate to the trunk soon. Robert Ramey "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.40 Thank 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
participants (3)
-
Enrico Carrara -
Robert Ramey -
Sohail Somani