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
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):
--------------------------------------------------------------------------
|**************************************************<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.
