Hi all,
seems as if I have found a solution.
If I transform the SDO to axiom like this, it looks clean (will do more
testing but initially it looked ok):
//------------------
axiom_document_t * doc = axiomHelper->toAxiomDoc(sdo);
axiom_node_t * ret = NULL;
if(doc != NULL)
{
ret = axiom_document_get_root_element(doc, env);
axiom_stax_builder_t * sb = axiom_document_get_builder(doc, env);
axiom_stax_builder_free_self(sb, env);
}
return ret;
//------------------
Essentially, the trick is not to call axiom_stax_builder_free() but
rather axiom_stax_builder_free_self().
This way the stax builder and the doc is freed but the node tree in
'ret' is left intact.
Comments?
Rgds,
tge
BTW: I found some more leaks in the AxiomHelper ... -> Tuscany SDO C++
On Mon, 2010-07-12 at 19:17 +0200, Thomas Gentsch wrote:
> Hi all,
>
> I did some more investigation and it looks as if indeed both the request
> an response nodes are freed properly.
> Looking at the valgrind stack I believe it is something else that is
> left over ...
>
> On Sun, 2010-07-11 at 12:37 +0200, Thomas Gentsch wrote:
> > Many thx for this pointer - it confirms the answer to question one:
> > [...]
> > > > So I create a returned axiom_node_t but eventually end up with a memory
> > > > leak:
> > > > ------------------
> > > > ==3461== 20,164 (40 direct, 20,124 indirect) bytes in 1 blocks are
> > > > definitely lost in loss record 975 of 980
> > > > ==3461== at 0x4025C1C: malloc (vg_replace_malloc.c:195)
> > > > ==3461== by 0x47C1CFC: axutil_allocator_malloc_impl (allocator.c:75)
> > > > ==3461== by 0x47A2E1C: axiom_stax_builder_create
> > > > (om_stax_builder.c:70)
>
> It is the stax builder that is not freed. Essentially the following
> happens:
> 1. my service produces an SDO and calls the AxiomHelper to transform it
> to an axiom node which I then return
> 2. the AxiomHelper does
> a) char * str = ... // Serialize the SDO to XML
> b) axiom_xml_reader_create_for_memory(env, str, ...)
> c) axiom_stax_builder_t* builder =
> axiom_stax_builder_create(env, reader);
> d) axiom_document_t* document =
> axiom_stax_builder_get_document(builder, env);
> e) axiom_node_t* root_node =
> axiom_document_get_root_element(document, env);
> f) axiom_document_build_all(document, env);
> and returns the "document" from which I extract the root node again
> which is the response node
>
> No matter what I try to free things:
> - the stax builder
> - the doc
> - I tried detaching the root node
> - tried extracting the stax builder from the doc and freeing it
> - ...
> either I get a double-free crash or the memory leak.
>
> Any ideas?
>
> Regarding the other one see below ...
>
> > > > ==3461== by 0x4712A66:
> > > > commonj::sdo_axiom::AxiomHelper::toAxiomDoc(commonj::sdo::RefCountingPointer<commonj::sdo::DataObject>,
> > > > char const*, char const*) (sdo_axiom.cpp:146)
> > > > ==3461== by 0x4438CB8:
> > > > dataObjToAxiom(commonj::sdo::RefCountingPointer<commonj::sdo::DataObject>)
> > > > (in /opt/bes/itm/modules/libimsoap.so)
> > > > ==3461== by 0x4439839: invokeFunc(axutil_env const*, axiom_node*)
> > > > (im_soapsrv.cpp:160)
> > > > ==3461== by 0x4439396: invoke(axis2_svc_skeleton*, axutil_env const*,
> > > > axiom_node*, axis2_msg_ctx*) (im_soapsrv.cpp:79)
> > > > ==3461== by 0x4C31C8D: soapSrvInvoke (im_soapsrvax.cpp:37)
> > > > ==3461== by 0x474B0D6:
> > > > axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync
> > > > (raw_xml_in_out_msg_recv.c:209)
> > > > ==3461== by 0x474A433: axis2_msg_recv_invoke_business_logic
> > > > (msg_recv.c:481)
> > > > ==3461== by 0x474AB34: axis2_msg_recv_receive_impl (msg_recv.c:403)
> > > > ==3461== by 0x474A4B3: axis2_msg_recv_receive (msg_recv.c:520)
> > > > ------------------
> [...]
> > > > Secondly, how is it supposed to work the other way around? In my
> > > > service, I receive an axiom node, transform it to a SDO etc.
> > > > Who is in charge of freeing the original axiom_node_t?
> > > > I don't do it in my code, so the result is another memory leak:
> > > >
> > > > -----------------------
> > > > ==3461== 8,737 (56 direct, 8,681 indirect) bytes in 1 blocks are
> > > > definitely lost in loss record 970 of 980
> > > > ==3461== at 0x4025C1C: malloc (vg_replace_malloc.c:195)
> > > > ==3461== by 0x47C1CFC: axutil_allocator_malloc_impl (allocator.c:75)
> > > > ==3461== by 0x47A022B: axiom_output_create (om_output.c:79)
>
> Again, it is not the node but the axiom_output_t which has been created
> in the AxiomHelper.
> Here I have added an
> axiom_output_free(output, the_env);
> in the AxiomHelper which seems to fix the second leak.
>
> Many thx,
> tge
>
> > > > ==3461== by 0x4712381:
> > > > commonj::sdo_axiom::AxiomHelper::toSdo(axiom_node*,
> > > > commonj::sdo::RefCountingPointer<commonj::sdo::DataFactory>, char
> > > > const*) (sdo_axiom.cpp:214)
> > > > ==3461== by 0x4438D9F: dataObjFromAxiom(axiom_node*)
> > > > (in /opt/bes/itm/modules/libimsoap.so)
> > > > ==3461== by 0x44397C0: invokeFunc(axutil_env const*, axiom_node*)
> > > > (im_soapsrv.cpp:152)
> > > > ==3461== by 0x4439396: invoke(axis2_svc_skeleton*, axutil_env const*,
> > > > axiom_node*, axis2_msg_ctx*) (im_soapsrv.cpp:79)
> > > > ==3461== by 0x4C31C8D: soapSrvInvoke (im_soapsrvax.cpp:37)
> > > > ==3461== by 0x474B0D6:
> > > > axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync
> > > > (raw_xml_in_out_msg_recv.c:209)
> > > > ==3461== by 0x474A433: axis2_msg_recv_invoke_business_logic
> > > > (msg_recv.c:481)
> > > > ==3461== by 0x474AB34: axis2_msg_recv_receive_impl (msg_recv.c:403)
> > > > ==3461== by 0x474A4B3: axis2_msg_recv_receive (msg_recv.c:520)
> > > > -----------------------
> > > >
> > > > Any hints are greatly appreciated!!
> > > >
> > > > Many thx + regards,
> > > > tge
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: c-user-unsubscr...@axis.apache.org
> > > > For additional commands, e-mail: c-user-h...@axis.apache.org
> > > >
> > > >
> > > >
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscr...@axis.apache.org
For additional commands, e-mail: c-user-h...@axis.apache.org
