[prev in list] [next in list] [prev in thread] [next in thread] 

List:       axis-c-user
Subject:    Re: Axis2/C Memory Leaks
From:       Samisa Abeysinghe <samisa () wso2 ! com>
Date:       2007-11-21 1:47:21
Message-ID: 47438B59.5030607 () wso2 ! com
[Download RAW message or body]

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


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

[prev in list] [next in list] [prev in thread] [next in thread]