[
https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562889#action_12562889
]
Supun Kamburugamuva commented on AXIS2C-933:
--------------------------------------------
Yes, I think we have a bug in the buffer. But I couldn't find it yet. I think
it is a memory corruption. The buffer was written at the last minute. So it
didn't undergo much testing.
I would like to add few lines about how the buffer works, because it is little
bit harder to find out everything from the code itself.
When guththila is reading from a callback function or a file it doesn't know
the exact length of the XML. But this can be easily done in the case of memory
reader. So we don't have a problem there.
What guththila does is, it reads the incoming XML, chunk at a time and store it
in the buffer. Guththila buffer is actually a collection of buffers (**buff
double pointer). Initially only one buffer is there (i.e buffer.buff[0]). Then
guththila fills this buffer with the incoming XML. Then it goes through this
buffer until all its data is been read by the parser. Then it allocates a new
buffer (i.e buffer.buff[1]) and this buffer size is greater than the previous
buffer.
There is an interesting thing happens when creating a new buffer. Guththila use
pointers to the buffer in guththila_token to keep track of the tokens. But when
a buffer is read to the end a token may be started but it may be not read to
the end (not closed). So if we go in the normal way one part of the token will
be in the end of a buffer and other part will be in the start of another
buffer. So the token becomes impossible to use. In guththila what I did is when
the above happens I moved the first half of the token from the buffer to the
newly allocated buffer. This way tokens are consistently placed in the buffers.
> guththila parser fails when incoming message longer than 16984 characters
> -------------------------------------------------------------------------
>
> Key: AXIS2C-933
> URL: https://issues.apache.org/jira/browse/AXIS2C-933
> Project: Axis2-C
> Issue Type: Bug
> Components: guththila
> Affects Versions: Current (Nightly)
> Environment: Windows XP, Visual Studio 2005, guththila, libcurl
> Reporter: Bill Mitchell
> Attachments: diff.txt
>
>
> The code in the guththila parser has a couple of problems when the first
> allocated buffer fills up and it attempts to read more data. First, when
> allocating another buffer it doubled the size of all the buffers allocated to
> this point, but then recorded the new buffer size as only equal to the size
> of all the previous buffers. Second, after fixing the buffer allocation
> issue, I discovered that the read into the buffer tried to read as much as
> all the buffers to date, instead of just the amount remaining in the buffer
> just allocated. There is also a subtle problem in the guththila_next_no_char
> routine if last_start is not set, that it did not assure that all the
> characters since next are moved to the newly allocated buffer.
> While debugging this, because of other issues, I walked through the path of
> an unexpected EOF in the middle of the incoming message, and discovered that
> several while loops in the parser do not stop on EOF, but just keep reading
> and reading and reading...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
