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

Bill Mitchell updated AXIS2C-925:
---------------------------------

    Attachment: soapfault.diff

In the attached diff, I took the quick and dirty approach of using 
axiom_soap_fault_text_set_base_node and axiom_soap_value_set_base_node to set 
the node pointer back to zero after the tree has been freed.  It might be more 
esthetically pleasing to define some new entry points, 
axiom_soap_fault_value_detach_base_node, etc., that would return the old node 
pointer, detach the node from its parent, and clear the pointer in the 
fault_value or fault_text, to make it more obvious that the caller is taking 
ownership of the node.  Or even an axiom_soap_fault_value_discard_base_node 
that did all the above and the axiom_node_free_tree call.  But using 
set_base_node to set the node pointer to zero does get the job done.  

With the fix in the attached diff, the SOAP 1.1 fault messages from the server 
were handled correctly by the svc_client and stub, and the client code was able 
to obtain invoke axiom_soap_fault_value_get_text and the other text accessors 
without error. 

> seg fault in axiom_soap_fault_get_text if SOAP 1.1
> --------------------------------------------------
>
>                 Key: AXIS2C-925
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-925
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: xml/soap
>    Affects Versions: Current (Nightly)
>         Environment: Windows XP, Visual Studio 2005, libxml2, libcurl
>            Reporter: Bill Mitchell
>         Attachments: soapfault.diff
>
>
> If a SOAP 1.1 server returns a SOAP fault, a seg fault can happen if the 
> client calls axiom_soap_fault_get_text.  At the time of the crash, using the 
> debugger the om_ele_node in the fault_value points to memory that has been 
> reused, probably as a result of being released.  When axiom_element_get_text 
> is called, the data_element it is passed appears to be overwritten or reused, 
> so axiom_element_get_text sees om_element->text_value as nonzero, tries to 
> free it, and the C runtime diagnoses a memory management error on the free.  
> Stepping through with the debugger, the crux of the problem lies in 
> soap_body.c, where axiom_soap_body_convert_fault_to_soap11 detaches the 
> fault_value_node, converts its contents to text, issues the free_tree to free 
> the node and its children, but leaves the pointer as the 
> axiom_soap_fault_value_base_node.  So the later call to 
> axiom_soap_fault_get_text believes there is still a node tree structure 
> present. The same oversight occurs when processing the fault_reason.  The 
> axiom_soap_fault_text_base_node is detached, converted to a single text 
> string, the node tree is freed, but the pointer is left as the 
> axiom_soap_fault_base_node.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to