I've been digging into this one, and am writing in to report my progress.
To refresh, this is in reference to the major memory leak caused by having
AXIOM_SOAP_ENVELOPE_FREE(msg_ctx->soap_envelope, env); commented out in
msg_ctx.c

When putting that line in, the code flows into axiom_soap_builder_free(),
axiom_stax_builder_free(), and axiom_document_free().  Somewhere in
axiom_document_free(), the application will crash.  This appears to be
caused by a double free, in which memory is owned by an
om_element->text_value and the "application-level" types used in the SOAP
message.

For example: here is a pseudo generated type:

axis2_MyType_free (...) {
   if (MyType_impl->attrib_MyText != NULL)
   {
       AXIS2_FREE( env-> allocator, MyType_impl->attrib_MyText);
       MyType_impl->attrib_MyText = NULL;
   }
}

axis2_MyType_build_om (...) {
   text_value = AXIOM_ELEMENT_GET_TEXT(current_element, env, current_node
);
   AXIS2_MYTYPE_SET_MYTEXT(MyType, env,
                                                         text_value);
}

axis2_MyType_set_MyText(param_MyText) {
   MyType_impl->attrib_MyText = param_MyText;
}


In this case, MyType has assumed ownership of the text returned by
axiom_element_get_text().  It will free it in its free function.  However,
if you look at axiom_element_get_text(), the following occurs:

axiom_element_get_text(...) {
...
dest = AXIS2_STRDUP(temp_text, env);
...
om_element->text_value = dest;
return om_element->text_value;
}

Then, in axiom_element_free():

axiom_element_free() {
   if (om_element->text_value)
   {
       AXIS2_FREE(env->allocator, om_element->text_value);
       om_element->text_value = NULL;
   }
}


The result of which, is that two objects lay claim to memory, and both try
to free it.  This obviously will cause a crash, and is, I'm guessing, why
the AXIOM_SOAP_ENVELOPE_FREE() was commented out in the first place.

I think what needs to be happening is that the WSDL->code generator needs to
be duplicating the text_values it reads before setting them.  Before 1.0,
this needs to be ironed out, so there is no discrepancy, because the memory
leak is very severe.

I'm posting the information so others can look into it as well.  I'd
appreciate knowing what other people discover, so that these items can be
addressed.

Thanks,
Jared

Reply via email to