Hi ,
Paul Fremantle wrote:
+1 samisa. It might be hard work now, but worth it.
Also I think based on the discussion we had with James, maybe its
possible to set some boundaries. We allocate all memory within that
execution path from a buffer, and free all memory from the buffer at
the end.
Like we extracted hash from apr why don't we extract the memory pool
from there too :)
damitha
Paul
On 10/26/05, *Sanjiva Weerawarana* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
On Wed, 2005-10-26 at 07:43 +0600, Samisa Abeysinghe wrote:
> Hi All,
> There are few more memory leaks present in the axis2 C code.
> (Guththila leaks should be handled seperate IMO)
>
> I would like to propose that we use the unit tests to
isolate memory
> leak problems as much as possible and fix those then and there.
I would
> like the allocation and de-allocation to be local to a given
> class(struct) and module. We should always be providing a free
interface
> that matches a create interface for each struct, and the free
mechanism
> should be responsible of dealing with all deallocations. If we
are to
> have too much coupling in terms of memory allocation and
deallocation
> across modules and structs, we would run into great trouble in
dealing
> with fixing leaks.
>
> IMHO, it will be a good practice to be concerned of memory leaks
> right from the begining and leave no room for memory leaks as
much as
> possible. So lets try ro keep the memory leaks to *zero* :)
+1 :). I can imagine this is a bit hard but if we are careful its not
impossible!
Sanjiva.
