Crash when serializing binary object to XML archive
Using Boost 1.36, I'm seeing a crash when serializing a 256K malloc
block
using binary_object to an XML archive, something like this:
using namespace boost;
serialization::binary_object dataObject =
serialization::make_binary_object(dataBlock, dataSize);
ar << serialization::make_nvp("data_contents", dataObject);
The crash is in
boost::archive::iterators::transform_width
Simon Fraser wrote:
Using Boost 1.36, I'm seeing a crash when serializing a 256K malloc block using binary_object to an XML archive, something like this:
There is a trak item which refers to transform_width. I would guess/hope that this will be resolved when that trak item is addressed. Robert Ramey
I found this one: http://svn.boost.org/trac/boost/ticket/1481 but it's closed as "wontfix" (by you), and it's not clear whether it's the same issue. If it is, shouldn't another ticket be opened to fix serialization not to use transform_width in this way? This crash prevents me from using XML serialization, so I'd appreciate any hints on workarounds. Thanks Simon On Sep 6, 2008, at 9:41 am, Robert Ramey wrote:
Simon Fraser wrote:
Using Boost 1.36, I'm seeing a crash when serializing a 256K malloc block using binary_object to an XML archive, something like this:
There is a trak item which refers to transform_width. I would guess/ hope that this will be resolved when that trak item is addressed.
Robert Ramey
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I changed my mind. There is currently an item on the active list which demonstrates how to fix it and this I will do. Assuming the problem is what I think it is, you might try a different size binary object - e.g. some multiple of 3 bytes. That should work around the problem. Robert Ramey Simon Fraser wrote:
I found this one: http://svn.boost.org/trac/boost/ticket/1481 but it's closed as "wontfix" (by you), and it's not clear whether it's the same issue. If it is, shouldn't another ticket be opened to fix serialization not to use transform_width in this way?
This crash prevents me from using XML serialization, so I'd appreciate any hints on workarounds.
Thanks Simon
On Sep 6, 2008, at 9:41 am, Robert Ramey wrote:
Simon Fraser wrote:
Using Boost 1.36, I'm seeing a crash when serializing a 256K malloc block using binary_object to an XML archive, something like this:
There is a trak item which refers to transform_width. I would guess/ hope that this will be resolved when that trak item is addressed.
Robert Ramey
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Sep 6, 2008, at 10:30 am, Robert Ramey wrote:
I changed my mind. There is currently an item on the active list which demonstrates how to fix it and this I will do.
That's good news, thanks. Could you point me to that item?
Assuming the problem is what I think it is, you might try a different size binary object - e.g. some multiple of 3 bytes. That should work around the problem.
Unfortunately the binary object size is an inherent property of my model and is not adjustable (unless I play games with adding 3 bytes to the end on write, and stripping them off on read, which I'd rather not do). Thanks Simon
Robert Ramey
Simon Fraser wrote:
I found this one: http://svn.boost.org/trac/boost/ticket/1481 but it's closed as "wontfix" (by you), and it's not clear whether it's the same issue. If it is, shouldn't another ticket be opened to fix serialization not to use transform_width in this way?
This crash prevents me from using XML serialization, so I'd appreciate any hints on workarounds.
Thanks Simon
On Sep 6, 2008, at 9:41 am, Robert Ramey wrote:
Simon Fraser wrote:
Using Boost 1.36, I'm seeing a crash when serializing a 256K malloc block using binary_object to an XML archive, something like this:
There is a trak item which refers to transform_width. I would guess/ hope that this will be resolved when that trak item is addressed.
Robert Ramey
participants (2)
-
Robert Ramey
-
Simon Fraser