[jira] Commented: (AXIS2C-933) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault

["Supun Kamburugamuva (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562971#action_12562971 ] 

Supun Kamburugamuva commented on AXIS2C-933:
--------------------------------------------

There is another thing that I couldn't mention. This is related to the guththila_token_t structure. Guththila token structures are created beforehand and stored in guththila_token_list_t structure (this is a structure cache). So when we want to use a token we have to get it from this list and when we are done with the token we have to release the token to the list. In guththila code we never create or free tokens and token_list handles that.

Onother small issue is that I neer used create methods for structures. Simple reason is that sometimes they can be inefficient due to the fact that they always allocate memory from the heap. But there are situations where we can use static allocations, but create methods doesn't permit this.  


> guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault
> ---------------------------------------------------------------------------------------------------
>
>                 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