You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Bill Mitchell (JIRA)" <ji...@apache.org> on 2008/01/26 05:55:34 UTC
[jira] Created: (AXIS2C-933) guththila parser fails when incoming
message longer than 16984 characters
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
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
[jira] Commented: (AXIS2C-933) guththila parser does not handle
incomplete messages well, leading to an infinite loop or seg fault
Posted by "Dinesh Premalal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563906#action_12563906 ]
Dinesh Premalal commented on AXIS2C-933:
----------------------------------------
Ok, That would be fine.
> 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
[jira] Updated: (AXIS2C-933) guththila parser does not handle
incomplete messages well, leading to an infinite loop or seg fault
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bill Mitchell updated AXIS2C-933:
---------------------------------
Attachment: guththila_xml_parser.diff
For reference, in the attached guththila_xml_parser.diff is the patch to just the problems described in this issue. I will apply it shortly.
> 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
> Fix For: 1.3.0
>
> Attachments: diff.txt, diff2.txt, guththila_xml_parser.diff
>
>
> 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
[jira] Updated: (AXIS2C-933) guththila parser fails when incoming
message longer than 16984 characters
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (AXIS2C-933) guththila parser does not handle
incomplete messages well, leading to an infinite loop or seg fault
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ 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
Supun, I see the cause of the confusion. When I uploaded a revised version of this patch, I mistakenly did not strip all the fixes to other modules from this patch. My bad.
I've fixed that error in the diff2.txt file, so it is just this fix combined with the fix already applied later to guththila for AXIS2C-857. So you can examine this to see if anything strikes you as really odd. Later today, I should have a chance to rebuild the patch against the current guththila_xml_parser.c source, so the patch will then include just this fix and not AXIS2C-857.
> 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
[jira] Commented: (AXIS2C-933) guththila parser fails when incoming
message longer than 16984 characters
Posted by "Supun Kamburugamuva (JIRA)" <ji...@apache.org>.
[ 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-933) guththila parser does not handle
incomplete messages well, leading to an infinite loop or seg fault
Posted by "Supun Kamburugamuva (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563902#action_12563902 ]
Supun Kamburugamuva commented on AXIS2C-933:
--------------------------------------------
Please don't commit them. I will commit them as soon as I go through them.
> 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
[jira] Updated: (AXIS2C-933) guththila parser does not handle
incomplete messages well, leading to an infinite loop or seg fault
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bill Mitchell updated AXIS2C-933:
---------------------------------
Summary: guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault (was: guththila parser fails when incoming message longer than 16984 characters)
> 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
[jira] Updated: (AXIS2C-933) guththila parser does not handle
incomplete messages well, leading to an infinite loop or seg fault
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bill Mitchell updated AXIS2C-933:
---------------------------------
Attachment: (was: diff2.txt)
> 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
>
>
> 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
[jira] Updated: (AXIS2C-933) guththila parser does not handle
incomplete messages well, leading to an infinite loop or seg fault
Posted by "Dinesh Premalal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dinesh Premalal updated AXIS2C-933:
-----------------------------------
Fix Version/s: 1.3.0
> 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
> Fix For: 1.3.0
>
> 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
[jira] Resolved: (AXIS2C-933) guththila parser does not handle
incomplete messages well, leading to an infinite loop or seg fault
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bill Mitchell resolved AXIS2C-933.
----------------------------------
Resolution: Fixed
Assignee: Bill Mitchell
> 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
> Assignee: Bill Mitchell
> Fix For: 1.3.0
>
> Attachments: diff.txt, diff2.txt, guththila_xml_parser.diff
>
>
> 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
[jira] Commented: (AXIS2C-933) guththila parser does not handle
incomplete messages well, leading to an infinite loop or seg fault
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565466#action_12565466 ]
Bill Mitchell commented on AXIS2C-933:
--------------------------------------
Fix included in svn rev 618364.
> 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
> Assignee: Bill Mitchell
> Fix For: 1.3.0
>
> Attachments: diff.txt, diff2.txt, guththila_xml_parser.diff
>
>
> 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
[jira] Commented: (AXIS2C-933) guththila parser does not handle
incomplete messages well, leading to an infinite loop or seg fault
Posted by "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
[jira] Commented: (AXIS2C-933) guththila parser does not handle
incomplete messages well, leading to an infinite loop or seg fault
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563043#action_12563043 ]
Bill Mitchell commented on AXIS2C-933:
--------------------------------------
The issue I alluded to above, that after applying the attached fix the client sees a partial message and no error, is reported separately in AXIS2C-936.
> 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
[jira] Commented: (AXIS2C-933) guththila parser does not handle
incomplete messages well, leading to an infinite loop or seg fault
Posted by "Dinesh Premalal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563862#action_12563862 ]
Dinesh Premalal commented on AXIS2C-933:
----------------------------------------
Hi Devs, Is this patches are complete? Can I commit them into svn ?
> 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
[jira] Updated: (AXIS2C-933) guththila parser fails when incoming
message longer than 16984 characters
Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bill Mitchell updated AXIS2C-933:
---------------------------------
Attachment: diff.txt
It is unfortunately not very easy and maybe not helpful to separate these changes from the ones already underdevelopment for AXIS2C-857. So I didn't try, those changes are also present in this patch.
Also included are two small related fixes, to detect and handle the out of memory situation when allocating more buffers, and to forego the initialization of variables not used in the normal next_char path as I expect its performance does matter.
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org