Serialization problem on 64-bit Windows release
We've started to use boost serialization and I've run into problems with
serialization of derived classes. The "funny" thing is that this happens
only on 64-bit Windows release compiled with MS Visual 2005. The same code
works fine on Linux 32/64 bit debug/release, on Windows 32-bit debug/release
and on Windows 64-bit debug. But not Windows 64-bit release. We use boost
version 1.33.1.
Here's the code that causes problems (Parameter is the base class,
ParamCollection is a vector of Parameters):
template<class Archive>
static void serialize(Archive & ar, ParamCollection & col, const
unsigned int /*version*/)
{
ar.register_type(static_cast
Looks like a compiler bug to me. You might try the BOOST_CLASS_EXPORT method. You might try the alternative registration syntax: ar.template register_type<FloatParameter>(); ... You might ask microsoft - lol Other than that I'm not sure what to suggest. Robert Ramey Sigurd Saue wrote:
We've started to use boost serialization and I've run into problems with serialization of derived classes. The "funny" thing is that this happens only on 64-bit Windows release compiled with MS Visual 2005. The same code works fine on Linux 32/64 bit debug/release, on Windows 32-bit debug/release and on Windows 64-bit debug. But not Windows 64-bit release. We use boost version 1.33.1.
Here's the code that causes problems (Parameter is the base class, ParamCollection is a vector of Parameters):
template<class Archive> static void serialize(Archive & ar, ParamCollection & col, const unsigned int /*version*/) { ar.register_type(static_cast
(NULL)); ar.register_type(static_cast (NULL)); ar.register_type(static_cast (NULL)); ar.register_type(static_cast (NULL)); ar.register_type(static_cast (NULL)); ar & boost::serialization::base_object
(col); }
When serializing the ParamCollection (serializing, not deserializing) an archive exception is thrown: unregistered class. I've tried to use both abstract and non-abstract base class without any success. I did some research in the boost code and found that the exception was thrown in polymorphic::save (oserializer.hpp) by the last condition (NULL == bpos_ptr).
Any clues? Is there a workaround?
Thanks, Sigurd
Thanks. You are probably right - interesting to hear if anyone else has had the same problem. I just wanted to make sure that there are no issues regarding size_t and pointer sizes that could cause this somewhere in the serialization library (improper initializations, etc.). I will try the other approaches shortly. Sigurd -----Opprinnelig melding----- Fra: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org]Pa vegne av Robert Ramey Sendt: 4. april 2006 17:27 Til: boost-users@lists.boost.org Emne: Re: [Boost-users] Serialization problem on 64-bit Windows release Looks like a compiler bug to me. You might try the BOOST_CLASS_EXPORT method. You might try the alternative registration syntax: ar.template register_type<FloatParameter>(); ... You might ask microsoft - lol Other than that I'm not sure what to suggest. Robert Ramey Sigurd Saue wrote:
We've started to use boost serialization and I've run into problems with serialization of derived classes. The "funny" thing is that this happens only on 64-bit Windows release compiled with MS Visual 2005. The same code works fine on Linux 32/64 bit debug/release, on Windows 32-bit debug/release and on Windows 64-bit debug. But not Windows 64-bit release. We use boost version 1.33.1.
Here's the code that causes problems (Parameter is the base class, ParamCollection is a vector of Parameters):
template<class Archive> static void serialize(Archive & ar, ParamCollection & col, const unsigned int /*version*/) { ar.register_type(static_cast
(NULL)); ar.register_type(static_cast (NULL)); ar.register_type(static_cast (NULL)); ar.register_type(static_cast (NULL)); ar.register_type(static_cast (NULL)); ar & boost::serialization::base_object
(col); }
When serializing the ParamCollection (serializing, not deserializing) an archive exception is thrown: unregistered class. I've tried to use both abstract and non-abstract base class without any success. I did some research in the boost code and found that the exception was thrown in polymorphic::save (oserializer.hpp) by the last condition (NULL == bpos_ptr).
Any clues? Is there a workaround?
Thanks, Sigurd
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Sigurd Saue
Thanks. You are probably right - interesting to hear if anyone else has had the same problem.
I will try the other approaches shortly.
Sigurd, I believe I have the same problem. My code fails to serialize a polymorphic class though the pointer to the base with the "unregistered class" error. The code works well on 32-bit Windows, but fails on 64-bit. However, the failure occurs only on one customer's machine (8 processors), I could not reproduce it on any of my test computers, including 64-bit with 4 processors. Did you find a workaround? Probably one of mentioned by Robert, or another one? Your help would be greatly appreciated. Sergey
Is it possible that this might be related to the recently discovered fact (at least by me) versions of the serialization library are, contrary to intention, not thread safe? That is, conflict occurs when multiple threads are using serilization even with different archive instances due to the fact that they share the same gobal extended_type_info table. This has been addressed - and hopefully remedied in 1.35. Robert Ramey Sergey Filippov wrote:
Sigurd Saue
writes: Thanks. You are probably right - interesting to hear if anyone else has had the same problem.
I will try the other approaches shortly.
Sigurd,
I believe I have the same problem. My code fails to serialize a polymorphic class though the pointer to the base with the "unregistered class" error. The code works well on 32-bit Windows, but fails on 64-bit. However, the failure occurs only on one customer's machine (8 processors), I could not reproduce it on any of my test computers, including 64-bit with 4 processors.
Did you find a workaround? Probably one of mentioned by Robert, or another one? Your help would be greatly appreciated.
Sergey
participants (3)
-
Robert Ramey
-
Sergey Filippov
-
Sigurd Saue