[serialization] bpos_ptr NULL in basic_oarchive_impl::save_pointer
I'm currently using 1_33_1 I've been having some problems with serialization so I built a test module that serializes a set of class template instantiations in a way that vaguely matches my real application. The template instances are derived classes from a common pure virtual base class. I got it to work properly in the test app, but then noticed I hadn't done BOOST_IS_ABSTRACT or BOOST_CLASS_EXPORT for the template instantiations like I had in my real classes. When I add BOOST_IS_ABSTRACT for the derived template instantiations, it compiles, but then crashes in save_pointer because bpos_ptr is NULL. The initial failure is higher in the call stack at boost::archive::detail::save_pointer_type<>::invoke (oserializer.hpp), where it requests the bpos_ptr from register_type. I realize NOW that it's probably performing as expected (except there's no assert) since the derived class is NOT abstract. I had run into problems (much) earlier where it appeared that I needed the BOOST_IS_ABSTRACT on the derived classes and not the base class but that may have been a side effect of other things I was doing wrong. It had not appeared to be a problem using the superfluous BOOST_IS_ABSTRACT until recently (switch to 1_33_1?). I note that the boost cvs tip version (for 1_34) also does not have an assert there. I'm not sure if that would have helped me figure out what was wrong, but at least an assert would terminate things closer to the source of the problem... Anyway - perhaps this will help someone else who's running into the NULL bpos_ptr problem... Thanks for your great work and support on the forum here! Hugh Hoover Enumclaw Software.
Hugh Hoover wrote:
I note that the boost cvs tip version (for 1_34) also does not have an assert there. I'm not sure if that would have helped me figure out what was wrong, but at least an assert would terminate things closer to the source of the problem...
exactly where do you think the assert should go? Robert Ramey
On May 20, 2006, at 09:16, Robert Ramey wrote:
Hugh Hoover wrote:
I note that the boost cvs tip version (for 1_34) also does not have an assert there. I'm not sure if that would have helped me figure out what was wrong, but at least an assert would terminate things closer to the source of the problem...
exactly where do you think the assert should go?
I think in boost::archive::detail::save_pointer_type<>::invoke (in oserializer.hpp) - right after it gets the bpos_ptr from register_type. I presume (but I'm not absolutely certain) that you should ALWAYS get back a valid bpos_ptr at this point? Adding one of those "you might have made this mistake" comments at that point with something about BOOST_IS_ABSTRACT on a derived class would have shortened my debugging time by DAYS - but I'm not certain if that's the main reason for the failure or if anything else could cause that kind of failure? Anyway - thanks for the quick reply and all of the excellent work! Hugh Hoover Enumclaw Software
Hugh Hoover wrote:
On May 20, 2006, at 09:16, Robert Ramey wrote:
Hugh Hoover wrote:
I note that the boost cvs tip version (for 1_34) also does not have an assert there. I'm not sure if that would have helped me figure out what was wrong, but at least an assert would terminate things closer to the source of the problem...
exactly where do you think the assert should go?
I think in boost::archive::detail::save_pointer_type<>::invoke (in oserializer.hpp) - right after it gets the bpos_ptr from register_type. I presume (but I'm not absolutely certain) that you should ALWAYS get back a valid bpos_ptr at this point?
I don't think so. It looks to me that a NULL bpos_ptr signfies an abstract class. and its not a mistake to serialize an abstract class - (the system calls the actual derived classes).
Adding one of those "you might have made this mistake" comments at that point with something about BOOST_IS_ABSTRACT on a derived class would have shortened my debugging time by DAYS - but I'm not certain if that's the main reason for the failure or if anything else could cause that kind of failure?
I'm not sure which compiler your using - but some implement is_abstract correctly - obviating the need for BOOST_IS_ABSTRACT. Maybe that's helpful. Robert Ramey
Anyway - thanks for the quick reply and all of the excellent work!
Hugh Hoover Enumclaw Software
On May 20, 2006, at 13:07, Robert Ramey wrote:
Hugh Hoover wrote:
should ALWAYS get back a valid bpos_ptr at this point?
I don't think so. It looks to me that a NULL bpos_ptr signfies an abstract class. and its not a mistake to serialize an abstract class - (the system calls the actual derived classes).
Ah - ok... then perhaps down further, like in oserializer::save_pointer where it's trying to dereference the bpos_ptr, assuming it has a valid one?
I'm not sure which compiler your using - but some implement is_abstract
gcc4 and vc8
correctly - obviating the need for BOOST_IS_ABSTRACT. Maybe that's helpful.
I can try checking if they're correct already and just drop my usage of BOOST_IS_ABSTRACT.
participants (2)
-
Hugh Hoover -
Robert Ramey