[ https://issues.apache.org/jira/browse/AXIS2C-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753445#action_12753445 ]
S.Uthaiyashankar commented on AXIS2C-1375: ------------------------------------------ Frank Zhou's macro is simple solution, but will not work for bigger messages because start element might be in a buffer lesser than (_buffer)->cur_buff-1. Ideally we have to search from buffer 0 until we find _pos. Hatim's solution is good, but I could not check all the cases. I felt Allan's solution was easy to understand and having less modification to the structures. So, I am committing that solution. > 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.