axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank Zhou (JIRA)" <>
Subject [jira] Created: (AXIS2C-1375) Guththila XML writer serialize soap incorrectly so that a soap message being sent out contains gabage characters
Date Fri, 05 Jun 2009 22:24:07 GMT
Guththila XML writer serialize soap incorrectly so that a soap message being sent out contains
gabage characters

                 Key: AXIS2C-1375
             Project: Axis2-C
          Issue Type: Bug
          Components: guththila
    Affects Versions: 1.6.0
         Environment: windows XP
            Reporter: Frank Zhou
            Priority: Blocker
             Fix For: 1.6.0

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):
The second buffer (Buffer length 32768):
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:
#define GUTHTHILA_BUF_POS(_buffer, _pos) 
 ((_buffer).buff[(_buffer).cur_buff] + _pos - (_buffer).pre_tot_data)

The bug occurs when it calcuate elem->prefix->start = GUTHTHILA_BUF_POS(wr->buffer,
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);
          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.

View raw message