Re: [Boost-users] [Serialization] a coupla crashes from hiearchycomplexity

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-11-16 12:45:44

Reusser, Edward wrote:
> Robert,
>
> The 1/2 megabyte string being converted is pure XML generated by the
> xml_oarchive and read in using xml_iarchive in the boost
> serialization library.  It is being inserted as a single tag of an
> XML item serialized entirely by the xml_oarchive and xml_iarchive in
> the boost serialization library.  I believe that there are only 5
> characters that need to be converted:  less than (<), greater than
> (>), quote ("), apostrophe ('), and ampersand (&).
>
> Changing a block of text containing these characters to their
> corresponding escape sequences doesn't seem very difficult to me.  It
> is being done completely automatically by the serialization library.

This is being done.  What's somewhat in the air are characters like
ascii 127 (rubout) ascii 07 (bell) ascii 0 (nul) etc.  Sometimes people
have had problems with strings which include non-text characters such
as these which can create problems with text based representations.
I mentioned this as something that could explain the problem that's all.

> Our current solution, which uses a text archive on the front end and
> stores the internal strings as xml seems to work for now and
> completely avoids this conversion.  I just wanted to let you know
> that the conversion routine in the boost serialization library
> doesn't work for large buffers.

The fact that xerces has problems with it also makes me wonder if
its something common between the two.

Note that text archive use as data independent system for strings.  It
records the size of the string then the raw characters with no escapes.
This might also suggest that there is an issue with html escapes.

The fact that the problem occurs at 1/2 MB string could also be
significant and might even point to something in the local stream
implementation.  Since XML is much more verbose, its possible
that moving to the text archive just hides the problem rather than
really fixes it.

> I had to laugh at your response at sending this library to you.

Thatis my function here.

I do believe you're on to something here - but I don't have enough
information to offer much help.

Robert Ramey