axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Mitchell (JIRA)" <j...@apache.org>
Subject [jira] Updated: (AXIS2C-933) guththila parser fails when incoming message longer than 16984 characters
Date Sun, 27 Jan 2008 06:35:37 GMT

     [ 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Mime
View raw message