[1.43][Serialization] Serialization library seriosly broken
As I alluded to in my mail yesterday, the serialization library seems to be utterly broken in the current trunk, and unfortunately in the current release branch as well. We're seeing assertions at application initialization time during serialization registration in the file void_cast.hpp, line 225. That is in debug builds. In release builds we're seeing aborts later on. These problems seem to be caused by registering the same type more than once but from different shared libraries. We do not intentionally register the types more than once, even more, we have no control over this. Here is the simplified code causing the multiple registrations from different modules: struct Parameter_impl : ::Par // ::Par is a C-struct { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & lambda; ar & allowedl; // more serialization going on } }; struct Parameter { boost::shared_ptr< Parameter_impl > p; // ... private: friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & p; } }; Note: no BOOST_..._EXPORT or other serialization macros are utilized in this file. This code is included by several files from different shared library modules as it is passed around. It is just including this file into compilation units from different shared libraries what causes the problems described above. All code worked before and still does with V1.42. If this error stays in the release branch the whole Boost release will be unusable for us, causing endless grief in the future. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
On 4/24/2010 6:54 AM, Hartmut Kaiser wrote:
All code worked before and still does with V1.42.
If this error stays in the release branch the whole Boost release will be unusable for us, causing endless grief in the future.
Robert, can you please comment asap? -- Eric Niebler BoostPro Computing http://www.boostpro.com
I'm looking at the SVN tree for the tag which corresponds to boost release 1.42 and I'm not finding it. That is I'm seeing https://svn.boost.org/svn/boost tags hmm - nothting that looks like release_1.42 I've also checked https://svn.boost.org/svn/boost branches same here - though I do see things like RC_1_34 So, where should I look in the SVN tree to find boost release 1.42 so that I might make a comparison the the current release branch head?. Robert Ramey
On 4/24/2010 10:44 AM, Robert Ramey wrote:
I'm looking at the SVN tree for the tag which corresponds to boost release 1.42 and I'm not finding it.
That is I'm seeing
https://svn.boost.org/svn/boost tags hmm - nothting that looks like release_1.42
https://svn.boost.org/svn/boost/tags/release/Boost_1_42_0/ -- Eric Niebler BoostPro Computing http://www.boostpro.com
AMDG Robert Ramey wrote:
I'm looking at the SVN tree for the tag which corresponds to boost release 1.42 and I'm not finding it.
That is I'm seeing
https://svn.boost.org/svn/boost tags hmm - nothting that looks like release_1.42
I've also checked
https://svn.boost.org/svn/boost branches same here - though I do see things like RC_1_34
So, where should I look in the SVN tree to find boost release 1.42 so that I might make a comparison the the current release branch head?.
https://svn.boost.org/svn/boost/tags/release/Boost_1_42_0 In Christ, Steven Watanabe
On 24 April 2010 18:44, Robert Ramey <ramey@rrsd.com> wrote:
So, where should I look in the SVN tree to find boost release 1.42 so that I might make a comparison the the current release branch head?.
On Apr 24, 2010, at 10:44 AM, Robert Ramey wrote:
I'm looking at the SVN tree for the tag which corresponds to boost release 1.42 and I'm not finding it.
That is I'm seeing
https://svn.boost.org/svn/boost tags hmm - nothting that looks like release_1.42
I've also checked
https://svn.boost.org/svn/boost branches same here - though I do see things like RC_1_34
So, where should I look in the SVN tree to find boost release 1.42 so that I might make a comparison the the current release branch head?.
https://svn.boost.org/svn/boost/tags/release/Boost_1_42_0 though I like to browse using the Trac browser, since it shows the last commit message for a folder. https://svn.boost.org/trac/boost/browser/tags/release/Boost_1_42_0 -- Marshall
Hartmut Kaiser wrote:
As I alluded to in my mail yesterday, the serialization library seems to be utterly broken in the current trunk, and unfortunately in the current release branch as well.
We're seeing assertions at application initialization time during serialization registration in the file void_cast.hpp, line 225. That is in debug builds. In release builds we're seeing aborts later on. These problems seem to be caused by registering the same type more than once but from different shared libraries.
We do not intentionally register the types more than once, even more, we have no control over this. Here is the simplified code causing the multiple registrations from different modules:
struct Parameter_impl : ::Par // ::Par is a C-struct { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & lambda; ar & allowedl; // more serialization going on } };
struct Parameter { boost::shared_ptr< Parameter_impl > p; // ... private: friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & p; } };
Note: no BOOST_..._EXPORT or other serialization macros are utilized in this file.
This code is included by several files from different shared library modules as it is passed around. It is just including this file into compilation units from different shared libraries what causes the problems described above.
All code worked before and still does with V1.42.
If this error stays in the release branch the whole Boost release will be unusable for us, causing endless grief in the future.
Regards Hartmut
--------------- Meet me at BoostCon www.boostcon.com
I'll take a look at this. According to the SVN log for void_cast.cpp this file hasn't been changed since November 29 so it's not just a tweak in an assert or some other trivial fix. Robert Ramey I very cursory examination indicates that it's not a trivial issue
On 4/24/2010 10:23 AM, Robert Ramey wrote:
Hartmut Kaiser wrote:
As I alluded to in my mail yesterday, the serialization library seems to be utterly broken in the current trunk, and unfortunately in the current release branch as well. <snip>
I'll take a look at this. According to the SVN log for void_cast.cpp this file hasn't been changed since November 29 so it's not just a tweak in an assert or some other trivial fix.
Robert Ramey
I very cursory examination indicates that it's not a trivial issue
Thanks for looking into this, Robert. As the release is looming, we naturally will have to consider the possibility of rolling back serialization to the 1.42 version. Can you tell us what the repercussions of doing that would be? Are there new features that other libraries are depending on? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
On 4/24/2010 10:23 AM, Robert Ramey wrote:
As the release is looming, we naturally will have to consider the possibility of rolling back serialization to the 1.42 version. Can you tell us what the repercussions of doing that would be? Are there new features that other libraries are depending on?
In principle I don't think this would be a problem. As far as I can remember, these changes mostly address sticky and arcane issues related to loading/unloading DLLS etc. So, rolling back might get some other complaints. So a hasty decision could result in a game of software whack-a-mole . It's to soon to panic - give me at least a little time to look into it. There's always time to panic if necessary. Also the documentation has been corrected and new examples have been added to clarify the concepts and demonstrate how to use the library for simpler tasks like logging. . These are important to me. But of course given the criteria of a "strictly improved release", this would not enter into any decision. Robert Ramey
Hartmut Kaiser wrote:
All code worked before and still does with V1.42.
I seems that the assert is included in 1.42 and there is only one small change since. Does your example dynamically unload DLLS and then continue on or does it just load them automatically at the beginning of the program (or first use) and just leave them around until the end. Robert Ramey
Hartmut, I've just made a change in void_cast.cpp. I tested it here and checked into the trunk(61546). Could you test this change ASAP? Robert Ramey
I've just made a change in void_cast.cpp. I tested it here and checked into the trunk(61546).
Could you test this change ASAP?
I will be able to test tomorrow evening only, but I definitely will test. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
Hartmut Kaiser wrote:
I've just made a change in void_cast.cpp. I tested it here and checked into the trunk(61546).
Could you test this change ASAP?
I will be able to test tomorrow evening only, but I definitely will test.
Regards Hartmut
You might want to check the change I made as well. The assert exists in 1.42 - the only difference in the file - void_cast.cpp is a small change I made to fix a memory leak. I'm not confident that my fix actually fixed it - but of course everything passes here. Robert Ramey
participants (6)
-
Daniel James -
Eric Niebler -
Hartmut Kaiser -
Marshall Clow -
Robert Ramey -
Steven Watanabe