[jira] Issue Comment Edited: (AXIS2C-1375) Guththila XML writer serialize soap incorrectly so that a soap message being sent out contains gabage characters

["Allan Schrum (JIRA)" <ji...@apache.org>]

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

Allan Schrum edited comment on AXIS2C-1375 at 8/27/09 8:19 AM:
---------------------------------------------------------------

The above files and patch fix this problem. This is "diff"ed against WSO's version of Guththila so it does not apply against the current SVN tree. Sorry.

The problem is the way the "wr->next" field is used with the GUTHTHILA_BUF_POS() macro. The macro definitions specifically says that it only works within the current buffer. The current pattern used in the code is:

[code]
int uri_start;

uri_start = wr->next;
guththila_write_xtoken(wr, uri, uri_len, env);
// do something else
namesp->name[0]->start = GUTHTHILA_BUF_POS(wr->buffer, uri_start);
[/code]

The problem is that performing the guththila_write_xtoken() can run past a buffer boundary which invalidates the value previously returned by wr->next. To fix this (which is what I did) is to change the pattern to look like this:

[code]
int uri_start;
guththila_char_t *uri_start_p;
guththila_write_xtoken(wr, uri, uri_len, env);
uri_start = wr->next - uri_len;
uri_start_p = GUTHTHILA_BUF_POS(wr->buffer, uri_start);
// do something else
namesp->name[0]->start = uri_start_p;
[/code]

The key is to use the wr->next pointer after performing the guththila_write_xtoken() call. By subtracting the known length from the wr->next value, the correct (post-boundary switched) position is calculated (and placed into uri_start for this example). You *should* immediate get the pointer using GUTHTHILA_BUF_POS() as further writes to the buffer may invalidate the value stored in uri_start. Now that you have the correct pointer in uri_start_p, you can use it at your leisure.

-Allan



      was (Author: allan.schrum):
    The above files and patch fix this problem. This is "diff"ed against WSO's version of Guththila so it does not apply against the current SVN tree. Sorry.

The problem is the way the "wr->next" field is used with the GUTHTHILA_BUF_POS() macro. The macro definitions specifically says that it only works within the current buffer. The current pattern used in the code is:

[code]
int uri_start;

uri_start = wr->next;
guththila_write_xtoken(wr, uri, uri_len, env);
// do something else
namesp->name[0]->start = GUTHTHILA_BUF_POS(wr->buffer, uri_start);
[/code]

The problem is that performing the guththila_write_xtoken() can run past a buffer boundary which invalidates the value previously returned by wr->next. To fix this (which is what I did) is to change the pattern to look like this:

[code]
int uri_start;
guththila_char_t *uri_start_p;
guththila_write_xtoken(wr, uri, uri_len, env);
uri_start = wr->next - uri_len;
uri_start_p = GUTHTHILA_BUF_POS(wr->buffer, uri_start);
// do something else
namesp->name[0]->start = uri_start_p;
[/code]

The key is to use the wr->next pointer after performing the guththila_write_xtoken() call. This gets the correct (post-boundary switched) position into uri_start. You *should* immediate get the pointer using GUTHTHILA_BUF_POS() as further writes to the buffer may invalidate the value stored in uri_start. Now that you have the correct pointer in uri_start_p, you can use it at your leisure.

-Allan


  
> Guththila XML writer serialize soap incorrectly so that a soap message being sent out contains gabage characters
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: AXIS2C-1375
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-1375
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: guththila
>    Affects Versions: 1.6.0
>         Environment: windows XP
>            Reporter: Frank Zhou
>            Assignee: S.Uthaiyashankar
>            Priority: Blocker
>             Fix For: Next Version
>
>         Attachments: guththila.diff, guththila_xml_writer.c, guththila_xml_writer.c, testGuththilaBufferError.xml, testingCodeSnappet.cpp
>
>
> OK, since no one reply to my question, I have to debug the code and found out that guththila has a bug in managing buffer when seriazlize thea axiom tree (the soap structure) before actually send out the request, and I have a potential fix. This is really a critical bug I think, so I hope some developers can take a look at this problem. I am attaching the test input data and code snappet to reproduce the problem.
>  
> Basically, the bug occurs in guththila_xml_writer.c. The guththila_xml_writer (I call it the soap serializer) maintains an array of buffers dynamically when it writes the soap structure into the buffers. The bug will occur in the following situation: 
>  
> Let's say I have an element <ns1:doDeleteFirst>12345</ns1:doDeleteFirst> somewhere in the soap structure. Now before this element, there are lots of other elements, and when the  guththila_xml_writer  trys to process this element, the first buffer is ALMOST full, it does not have enough space to write the whole element name <ns1:doDeleteFirst> (the start tag) into the buffer, it has to create a new buffer, so it writes <ns1: at the end of the first buffer (still a few more bytes left empty), and writes "doDeleteFirst" at the very beginning of the second buffer.
>  
> The first buffer (Buffer length 16384):
> --------------------------------------------------------------------------
> |**************************************************<ns1:--|
>  
> The second buffer (Buffer length 32768):
> ---------------------------------------------------------------------------------------------------------------------------
> |doDeleteFirst-------------------------------------------------------------------------------------------------------------|
>  
> As the second buffer becomes the current buffer, when the writer trys to process the end tag (</ns1:doDeleteFirst>),  it uses an elem stack to track the namespace prefix and localname as in the following code: (starting from line 1396)
>  
>           elem->name = guththila_tok_list_get_token(&wr->tok_list, env);
>           elem->prefix = guththila_tok_list_get_token(&wr->tok_list, env);
>           elem->name->start = GUTHTHILA_BUF_POS(wr->buffer, elem_start);
>           elem->name->size = elem_len;
>           elem->prefix->start = GUTHTHILA_BUF_POS(wr->buffer, elem_pref_start);
>           elem->prefix->size = pref_len; 
>  
> The macro GUTHTHILA_BUF_POS  is defined as this:
>  
> #ifndef GUTHTHILA_BUF_POS
> #define GUTHTHILA_BUF_POS(_buffer, _pos) 
>  ((_buffer).buff[(_buffer).cur_buff] + _pos - (_buffer).pre_tot_data)
> #endif
> The bug occurs when it calcuate elem->prefix->start = GUTHTHILA_BUF_POS(wr->buffer, elem_pref_start):
>  
> The elem_pref_start has a value of 16375, the pre_tot_data has a value of 16379 (the first buffer length is 16384), they are calculated based on the first buffer data, but the current buffer is the second one, so  elem->prefix->start points to gabage!
>  
> I hope this makes sense to you. Use my test case you will see this quickly. When you run the same XML data I attached, first set a break point at line 392 in the file guththila_xml_writer_wrapper, and set the hit count as 514 in the break properties (the 514th element in <ns1:doDeleteFirst>), then debug step by step.
>  
> The potential fix is to define GUTHTHILA_BUF_POS as the following:
>  
>      if ((_buffer)->pre_tot_data > _pos)
>           return ((_buffer)->buff[(_buffer)->cur_buff-1] + _pos);
>      else
>           return ((_buffer)->buff[(_buffer)->cur_buff] + _pos - (_buffer)->pre_tot_data);
> GUTHTHILA_BUF_POS is used everywhere, so I really hope some developer can take over this case and fix it!
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.