axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Gentsch ...@e-tge.de>
Subject Re: Memory handling in Axis2c server
Date Tue, 13 Jul 2010 09:28:24 GMT

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-unsubscribe@axis.apache.org
> > > > For additional commands, e-mail: c-user-help@axis.apache.org
> > > >
> > > >
> > > >   



---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org


Mime
View raw message