Problem with boost archive. Cannot solve in any way.
Hello. I have this code, which throws an exception and I cannot find in any way why. It throws an invalid_signature exception. I'm sure that the serialized data where it comes this data from is correct. The code: std::string data_bytes(std::get<1>(*datos).begin(), std::get<1>(*datos).end()); std::istringstream stream(data_bytes); MensajeRed msg; //FIXME: This constructor throws boost::archive::binary_iarchive archive(stream); archive >> msg; Throws in the constructor of boost::binary_iarchive. Thanks in advance.
Germán Diago wrote:
Hello. I have this code, which throws an exception and I cannot find in any way why. It throws an invalid_signature exception. I'm sure that the serialized data where it comes this data from is correct. The code:
std::string data_bytes(std::get<1>(*datos).begin(), std::get<1>(*datos).end()); std::istringstream stream(data_bytes); MensajeRed msg;
//FIXME: This constructor throws boost::archive::binary_iarchive archive(stream); archive >> msg;
Throws in the constructor of boost::binary_iarchive. Thanks in advance.
Where did the serialized data come from? Binary archives aren't portable...
Where did the serialized data come from? Binary archives aren't portable...
From a binary archive, but it sends data between processes in the same computer (for now). The data is being serialized through boost.asio. Is there any problem with that? Thanks.
______________________________________________
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Germán Diago wrote:
Where did the serialized data come from? Binary archives aren't portable...
From a binary archive, but it sends data between processes in the same computer (for now). The data is being serialized through boost.asio. Is there any problem with that? Thanks.
______________________________________________
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Then your binary data is likely being interpreted as text, especially since you don't open the stringstream in binary mode.
Then your binary data is likely being interpreted as text, especially since you don't open the stringstream in binary mode.
I tried to correct the opening of archives in binary mode with no luck. I also tried to send data as plain text with no luck either. I'm using boost 1.44. Can anyone confirm if this is a bug or it's my fault? I bet it's the second, but I can't imagine why :-(. Thanks in advance.
I had a problem with 1.44 binary archive thowing bad_allocs and stream_errors: http://groups.google.com/group/boost-list/browse_thread/thread/8a871c336554c... The same code worked fine if I switched to boost-1.43 or to text_archive or just compiled on Fedora box instead of Ubuntu one... I finally switched to text_archive. On 22 September 2010 02:07, Germán Diago <germandiago@gmail.com> wrote:
Then your binary data is likely being interpreted as text, especially
since
you don't open the stringstream in binary mode.
I tried to correct the opening of archives in binary mode with no luck. I also tried to send data as plain text with no luck either. I'm using boost 1.44. Can anyone confirm if this is a bug or it's my fault? I bet it's the second, but I can't imagine why :-(. Thanks in advance. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Paul Graphov wrote:
I had a problem with 1.44 binary archive thowing bad_allocs and stream_errors:
http://groups.google.com/group/boost-list/browse_thread/thread/8a871c336554c...
The same code worked fine if I switched to boost-1.43 or to text_archive or just compiled on Fedora box instead of Ubuntu one...
Note: I have another project which is hung up on a bug with the gcc compiler on Ubuntu. (Ubuntu bug # 629092). I've been unable to get anyone to take it seriously though. The bug is sufficiently fundamental that I wouldn't expect the serialization library to work on that platform. Robert Ramey
On 22 Sep 2010, at 15:25, Robert Ramey wrote:
Paul Graphov wrote:
I had a problem with 1.44 binary archive thowing bad_allocs and stream_errors:
http://groups.google.com/group/boost-list/browse_thread/thread/8a871c336554c...
The same code worked fine if I switched to boost-1.43 or to text_archive or just compiled on Fedora box instead of Ubuntu one...
Note: I have another project which is hung up on a bug with the gcc compiler on Ubuntu. (Ubuntu bug # 629092). I've been unable to get anyone to take it seriously though. The bug is sufficiently fundamental that I wouldn't expect the serialization library to work on that platform.
There is no bug in the compiler, your program is faulty. The problem is that you are including <stdio.h>, which includes <sys/types.h> in main.c before defining #define _FILE_OFFSET_BITS 64. The second include in TESTRIO is then ignored. This leads to inconsistent definitions of structures in the two different files and a seg fault. You can either: 1) put #define _FILE_OFFSET_BITS 64 at the top of main.c 2) include "testrio.h" before <stdio.h> in main.c either of these fix your problem. Chris
Christopher Jefferson wrote:
Note: I have another project which is hung up on a bug with the gcc compiler on Ubuntu. (Ubuntu bug # 629092). I've been unable to get anyone to take it seriously though. The bug is sufficiently fundamental that I wouldn't expect the serialization library to work on that platform.
There is no bug in the compiler, your program is faulty. The problem is that you are including <stdio.h>, which includes <sys/types.h> in main.c before defining #define _FILE_OFFSET_BITS 64. The second include in TESTRIO is then ignored. This leads to inconsistent definitions of structures in the two different files and a seg fault.
You can either:
1) put #define _FILE_OFFSET_BITS 64 at the top of main.c 2) include "testrio.h" before <stdio.h> in main.c
either of these fix your problem.
I will try this. I'm not sure it's fair to characterise my example as faulty though. In any case, Thank you very much. Robert Ramey
participants (2)
-
Christopher Jefferson -
Germán Diago -
Kenny Riddile -
Paul Graphov -
Robert Ramey