Uploaded image for project: 'Axis2-C'
  1. Axis2-C
  2. AXIS2C-1375

Guththila XML writer serialize soap incorrectly so that a soap message being sent out contains gabage characters



    • Bug
    • Status: Resolved
    • Blocker
    • Resolution: Fixed
    • 1.6.0
    • 1.7.0
    • guththila
    • None
    • windows XP


      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:

      #ifndef GUTHTHILA_BUF_POS
      #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, 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);
      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!


        1. testGuththilaBufferError.xml
          17 kB
          Frank Zhou
        2. testingCodeSnappet.cpp
          1 kB
          Frank Zhou
        3. guththila_xml_writer.c
          79 kB
          Hatim Daginawala
        4. guththila_xml_writer.c
          80 kB
          Allan Schrum
        5. guththila.diff
          24 kB
          Allan Schrum



            shankar Selvaratnam Uthaiyashankar
            fchou99 Frank Zhou
            0 Vote for this issue
            2 Start watching this issue