axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allan Schrum (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (AXIS2C-1375) Guththila XML writer serialize soap incorrectly so that a soap message being sent out contains gabage characters
Date Thu, 27 Aug 2009 15:21:00 GMT

    [ 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.


Mime
View raw message