[Serialization] Boost 1.33 serialization const problem
Hello list,
currently I am trying to get serialization to work.
It worked well when I was using boost 1.32, but since I upgraded to 1.33 I'm having some problems.
In short;
I have an abstract base class and a derived class. I try to serialize/deserialize the derived class
through a pointer to the base class.
This worked well when I was using 1.32.
When I upgraded to 1.33 I got the static assert which trapped the 'saving non const error' (I hope this makes sense ..).
So I fixed it by following instructions from other posts dealing with the same problem
(basically just by changing 'base *b' to 'const base * const b').
The fix resolved the compile error, only now I'm getting a segfault at runtime.
The segfault happens during deserialization (when trying to 'reconstruct' the original object).
The funny thing is, I've tested it on a system (suse enterprise system 9, gcc 3.3.3) and it chrashes.
On another system (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) it works fine.
I reproduced the problem in a very small program located at the end of this post. Maybe someone
can have a look at the code and tell me whether there are obvious problems with my code or not.
If I know for sure that my code should run correctly, I'll just move on to an other linux distro ..
Thanks in advance,
Oscar
#include
I've compiled and run your example on my VC 7.1 setup using the the version in the HEAD and it compiles and executes fine. Your experiments suggest that it is a compiler dependent issue. So I can't pinpoint anything. However, I could offers some suggestions on your example which might or might not help. Feel free to accept or reject them. Your example looks correct to me. But includes a number of behaviors which to me are a little non-obvious to me and I sort of distrust compilers to get it right when its not obvious to me. a) I wouldn't have named a function string serialize(...). I'm concerned about the compiler getting the overloading wrong. At the very least it makes the example harder to understand. b) The following bit: string serialize(const base * const b){
I've compiled and run your example on my vc 7.1 system and it works fine. So there's not a lot I can say. But that won't stop me from offering a couple of suggestions: Your example looks correct to me - and it compiles and runs well - But I have a couple of quesions about it. a) The usage of a function string serialize(...) is not incorrect, but it could be confusing to a compiler with an issue with overloading. At the very least it makes the example harder to follow and might make error messages undecipherable. b) The following usage of string stream makes me wonder: string serialize(const base * const b){ stringstream str; boost::archive::text_oarchive oa(str); oa << b; return str.str(); } The order of destruction is: return (copy? string) destroy archive - this might add closing characters to the archive destroy string stream So I'm not certain that the string contains all the characters added to the archive. So I would try reformlating your example like the following: ... BOOST_IS_ABSTRACT(base); BOOST_CLASS_EXPORT(derived); int main(){ stringstream str; const base * const d1 = new derived(52,"a string"); { d1->do_it(); boost::archive::text_oarchive oa(str); oa << d1; } base *d2; { boost::archive::text_iarchive ia(str); ia >> d2; d2->do_it(); } return 0; }
Hi Robert, thanks for your quick reply. On Tue, Dec 12, 2006 at 09:20:49AM -0800, Robert Ramey wrote:
a) The usage of a function string serialize(...) is not incorrect, but it could be confusing to a compiler with an issue with overloading. At the very least it makes the example harder to follow and might make error messages undecipherable.
Ok, I'll fix that. Just to be sure ..
b) The following usage of string stream makes me wonder:
The order of destruction is:
return (copy? string) destroy archive - this might add closing characters to the archive destroy string stream
So I'm not certain that the string contains all the characters added to the archive.
That could make sense. I'll try it out tomorow at work and I will also test your reformulated example. Thanks again, Oscar
Hi Robert, On Tue, Dec 12, 2006 at 09:20:49AM -0800, Robert Ramey wrote:
So I would try reformlating your example like the following:
...
I tried your suggestions, but on the Suse gcc 3.3.3 I still get the segfault. For now, I will switch platforms/compilers (your library has proven to be very usefull in the past for us) .. regards, Oscar
I would be very interested in getting to the bottom of the problem. This would likely result in a small tweak which would make the library more portable. Of course I realise that this is not that easy. Note that I test here with gcc 3.3 under cywin. So I would be hopeful that its easily fixable. I don't know what version of boost your using, but it may already be fixed in a later version. Robert Ramey vermaaso wrote:
Hi Robert,
On Tue, Dec 12, 2006 at 09:20:49AM -0800, Robert Ramey wrote:
So I would try reformlating your example like the following:
...
I tried your suggestions, but on the Suse gcc 3.3.3 I still get the segfault. For now, I will switch platforms/compilers (your library has proven to be very usefull in the past for us) ..
regards, Oscar
On Wed, Dec 13, 2006 at 08:29:40AM -0800, Robert Ramey wrote:
I would be very interested in getting to the bottom of the problem. This would likely result in a small tweak which would make the library more portable. Of course I realise that this is not that easy. Note that I test here with gcc 3.3 under cywin. So I would be hopeful that its easily fixable. I don't know what version of boost your using, but it may already be fixed in a later version.
According to the website of Novell, they use 'GCC 3.3.3 enhanced by the SUSE labs team'. I need to a run patch on this system, but I'm not sure whether this patch will affect gcc. I'll try it anyway and run the same tests again. I'll report the results back later (probably tomorow). If you have any suggestions or tests you want me to run on this system just let me know. The boost version is boost 1_33_1. I'll check for a newer version also. Regards, Oscar
If you suspect the compiler I would run the whole test suite. It might take overnight - but its much better then waiting for anomolies to appear in your code and trying to track them down on a case by case basis. You can run just the serialization part of the test suite, but you might as well just follow the instructions with 1.33 and just re-run the whole thing. That wil give you table of any and all issues the version of the compiler you're using might have. Robert Ramey vermaaso wrote:
On Wed, Dec 13, 2006 at 08:29:40AM -0800, Robert Ramey wrote:
I would be very interested in getting to the bottom of the problem. This would likely result in a small tweak which would make the library more portable. Of course I realise that this is not that easy. Note that I test here with gcc 3.3 under cywin. So I would be hopeful that its easily fixable. I don't know what version of boost your using, but it may already be fixed in a later version.
According to the website of Novell, they use 'GCC 3.3.3 enhanced by the SUSE labs team'. I need to a run patch on this system, but I'm not sure whether this patch will affect gcc. I'll try it anyway and run the same tests again. I'll report the results back later (probably tomorow).
If you have any suggestions or tests you want me to run on this system just let me know.
The boost version is boost 1_33_1. I'll check for a newer version also.
Regards, Oscar
Hi Robert, On Thu, Dec 14, 2006 at 09:05:05AM -0800, Robert Ramey wrote:
If you suspect the compiler I would run the whole test suite. It might take overnight - but its much better then waiting for anomolies to appear in your code and trying to track them down on a case by case basis. You can run just the serialization part of the test suite, but you might as well just follow the instructions with 1.33 and just re-run the whole thing. That wil give you table of any and all issues the version of the compiler you're using might have.
I'm still working on running the tests. It looks like the serialization tests all passed, and currently I'm running all tests of the complete source tree. I noticed that a lot of tests in the type_traits have failed, but BOOST_IS_ABSTRACT should solve that, right ? regards, Oscar
vermaaso wrote:
Hi Robert,
I'm still working on running the tests. It looks like the serialization tests all passed, and currently I'm running all tests of the complete source tree. I noticed that a lot of tests in the type_traits have failed, but BOOST_IS_ABSTRACT should solve that, right ?
BOOST_IS_ABSTRACT "solves" it for the serialization library. Actually it would be better to say BOOST_IS_ABSTRACT works around the issue for compilers which don't pass the is_abstract type trait test. I made BOOST_IS_ABSTRACT so that there would be an "is_abstract" trait for compilers which didn't support the automatic one. I don't know if BOOST_IS_ABSTRACT has been used by other libraries for such a purpose. I would expect that for compilers which support is_abstract related type traits tests would fail but that libraries which depend upon this trait would document usage of BOOST_IS_ABSTRACT is permit the library to function inspite if lack of such a trait. I don't know if there are any libraries other than serialization which require this. Robert Ramey
Hi Robert, On Wed, Dec 13, 2006 at 08:29:40AM -0800, Robert Ramey wrote:
I would be very interested in getting to the bottom of the problem. This would likely result in a small tweak which would make the library more portable. Of course I realise that this is not that easy. Note that I test here with gcc 3.3 under cywin. So I would be hopeful that its easily fixable. I don't know what version of boost your using, but it may already be fixed in a later version.
It looks like the problem is fixed (or at least, workaround-ed).
When I change
string serialize(const base * const b)
to
string serialize(base * const b)
the problem goes away (I don't get the segfault anymore).
I ran the regression tests on the suse (gcc 3.3.3) machine and the serialization tests all pass (except
for test_static_warning which gives a warn, but I guess that is what's supposed to happen).
I am going to use the workaround (remove the first 'const') and consider this thread closed.
Except when you want to investigate some more, I'll be glad to help, but then I need specific
instructions on what to test because this is getting a bit over my head ...
For completeness I included the original message once more at the bottom of this post.
Regards and thanks for your suggestions,
Oscar
-- Original Message:
currently I am trying to get serialization to work.
It worked well when I was using boost 1.32, but since I upgraded to 1.33 I'm having some problems.
In short;
I have an abstract base class and a derived class. I try to serialize/deserialize the derived class through a pointer to the
base
+class.
This worked well when I was using 1.32.
When I upgraded to 1.33 I got the static assert which trapped the 'saving non const error' (I hope this makes sense ..).
So I fixed it by following instructions from other posts dealing with the same problem (basically just by changing 'base *b'
to
+'const base * const b').
The fix resolved the compile error, only now I'm getting a segfault at runtime.
The segfault happens during deserialization (when trying to 'reconstruct' the original object).
The funny thing is, I've tested it on a system (suse enterprise system 9, gcc 3.3.3) and it chrashes.
On another system (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) it works fine.
I reproduced the problem in a very small program located at the end of this post. Maybe someone
can have a look at the code and tell me whether there are obvious problems with my code or not.
If I know for sure that my code should run correctly, I'll just move on to an other linux distro ..
Thanks in advance,
Oscar
#include
participants (2)
-
Robert Ramey
-
vermaaso