[
https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Mitchell updated AXIS2C-933:
---------------------------------
Attachment: diff2.txt
I agree, Supun, that I misunderstood the buffs variable as accumulating the
size of all the buffers to date. It is in fact the size of just this buffer.
And, although I understood the logic of copying the start of the token from the
last buffer to the new buffer, I was imagining only the easy case of a short
token, where another buffer of the same size works fine. The doubling in size
handles the unusual case when a large amount of element content must be copied
from the previous buffer.
I suspected, after I wrote up the issue, that it was better seen from the last
problem forward. As I was unintentionally testing the path of an incomplete
message from the service, the core issue is that there are several while loops
in guththila that do not exit on end-of-file. So they continue to call
guththila_next_char. This infinite loop leads to a secondary failure, as
guththila_next_char will allocate another buffer, double in size, on each
attempt to read at end-of-file. Eventually this memory allocation fails, but
as guththila does not check for memory allocation failure, the ending symptom
is a seg fault in the buffer management logic.
Attached is a revised version of the first patch, that leaves the buffer
doubling logic intact, but remedies all the other issues I described and
addressed in the first patch.
Having implemented a fix for this, I discovered that the fact that the message
is incomplete gets lost in the upper layers, so the client ends up seeing a
partial message as if it is the entire message. But that is a different issue
that can be addressed separately.
> 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, diff2.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]
