Subra A Narayanan wrote:
So there are still some known memory leak issues in axis2/c? I have
been doing some testing to look for memory leaks and I do see that
memory is being lost. I am using apache and _not_ the simple axis
server.
With Apache module, you are better off, because of the use of apr pools.
We have plugged our allocator to apr pool mechanisms and we can be
assured we are in good hands.
There would be a slight memory growth, due to the operation contexts
being stored in the global pool, however, IMHO that is something that we
can live with for the time being.
Once we figure out the shared memory mechanisms, that too would be
hopefully solved.
do we know when axis 1.2 is scheduled to be released? we are getting
pretty close to our launch date, thats why I am concerned.
1.2 could be released in another months time.
the memory leaks that you have found, are they significant?
We have hit zero for echo samples in the early releases. I am sure this
time too we could be able to do that.
The generated code would have possibilities of memory leaks. That needs
to be looked into.
Samisa...
ur input is much appreciated.
Subra
On Nov 19, 2007 9:30 PM, <[EMAIL PROTECTED]> wrote:
Hi Edward,
I've recently being fixing memory leaks in Axis2/C (using libxml2 parser).
As far as I know, all the samples that we have do free all the resources
before they exit, when the latest fixes would be done in 1.2.0. I haven't
tried any generated code by the WSDL2C tool however, to see whether they
do the freeing properly.
*** If you could take a look at how the "echo" sample [axis2/c/samples] is
implemented in both client and server sides, it should help. ***
Please note that there are some "still reachable blocks" when you valgrind
and I'm not sure whether it is a valgrind issue with glibc, or whether it
is a dangling pointer, but there are no definite losses or indirect losses
at the moment. Somebody correct me if I have made a wrong conclusion.
On the other hand, there are still quite a number of leaks when you use
the Guththila parser, which we are looking forward to fix.
If you believe that the code generated by the codegen tool, lacks the
freeing of memory, as in the samples that are provided, please feel free
to raise an issue at the JIRA, and propose a patch.
N.B. I'm not sure whether all the patches that I proposed are reflected on
the current svn. But, I'm pretty sure that they would be, with the Axis2/C
1.2.0 release.
Hi,
I am designing some web service client code using the Axis2/C framework
(used WSDL2C to generate client stubs that call the framework). I have
a separate executable C file (C file that a main()) that calls the stub.
When I ran valgrind initially on it, I saw many memory leaks from this;
49 loss records to be exact. However, after inserting axis2_stub_free
and axutil_env_free before my end return statement in my executable C
file, I noticed that the loss records decreased greatly to 5. I noticed
that this freeing of the stub and env variables is not in the sample
client code. Should the sample client code also demonstrate this
freeing, and is this freeing logical to do on the client side? Also, I
did some initial tests on the server side and noticed many memory leaks
as well. Should this client-side freeing be also implemented on my
server code, or is the server-side freeing done differently and how if
anyone can describe where to insert the freeing statements?
Thanks,
Edward
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
