Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Message-ID: <1461686791.1248795014811.JavaMail.jira@brutus>
Date: Tue, 28 Jul 2009 08:30:14 -0700 (PDT)
From: "Hatim Daginawala (JIRA)" <jira@apache.org>
To: axis-c-dev@ws.apache.org
Subject: [jira] Updated: (AXIS2C-1375) Guththila XML writer serialize soap
 incorrectly so that a soap message being sent out contains gabage
 characters
In-Reply-To: <705932399.1244240647346.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/AXIS2C-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hatim Daginawala updated AXIS2C-1375:
-------------------------------------

    Attachment: guththila_xml_writer.c

The macro solution suggested did not work for me. I am attaching modified guththila_xml_writer.c. Now guththila_write_start_* and guththila_write_end_* functions respect the buffer boundary when writing start and end tags. I have tested this in my application and it seems to be working without any issues. I would appreciate if someone from the development team can review and apply this patch.

Please let me know if you have any questions/comments.

Thank you!

P.S: I cannot access CVS/SVN repository from our network so I am unable to create a patch against the repo.


> 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_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.