axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Brown <gordonw.br...@yahoo.com>
Subject Re: soap in client call contains gabage character -- A critical bug in guththila writer
Date Fri, 05 Jun 2009 21:15:42 GMT
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!

Thanks!
Gordon




________________________________
From: Gordon Brown <gordonw.brown@yahoo.com>
To: axis-c-user@ws.apache.org
Cc: axis-c-dev@ws.apache.org
Sent: Wednesday, June 3, 2009 12:49:21 AM
Subject: soap in client call contains gabage character -- Very very puzzling


Hi All,

I need urgent help with a very puzzling issue with axis2/c 1.6 ( I build the axis2/c using
the code from trunk, slightly earlier before the offical release). Here is my issue:

I have a small XML data (16K) passed in to be as a UTF8 string, I checked the XML data is
good (run through quite a few other tools to verify it). Now I used axiom APIs to parse the
XML and make web service call like this:

=========
xml_reader = axiom_xml_reader_create_for_memory(_env, (
AXIS2_XML_PARSER_TYPE_BUFFER);
 
om_builder = axiom_stax_builder_create(_env, xml_reader);void*)xmlString_in.c_str(), xmlString_in.size(),
"utf-8", 
axiom_document_t *document = axiom_stax_builder_get_document(om_builder, _env); 
axiom_node_t * payload = axiom_document_get_root_element(document, _env);
 
........
 axiom_node_t * node = axis2_svc_client_send_receive(_wsf_service_client, _env, payload );
============
 
Now I use tcpmon to intercept the call, I noticed that the data sent out contains some gabage
characters (always in some XML tag, not the element value) like this:
 
    <ns1:doDeleteFirst>12345</ù:doDeleteFirst>
 
However, if I serialize the payload node before I make the client call, I can see the data
is fine in memory. What puzzles me even more is that this thing only occur in one XML file
I tried, but works fine for many other XML input (even as big as 10M bytes).  I've also attached
the XML I used to procude the problem.
 
Does anyone have a clue about this?
 
Thanks much in advance!

Gordon


      
Mime
View raw message