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 Mon, 12 Jul 2010 17:17:20 GMT

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