Memory leaking when using Bazaar branches

[Nicholas Allen]

Has this patch made it into 1.13? I am still noticing that Bazaar leaks 
memory.

Cheers,

Nick

On Saturday 07 March 2009 23:11:55 John Arbash Meinel wrote:
> Nicholas Allen wrote:
> > Hi,
> >
> > I am not an expert Python programmer by any means but I think there may
> > be bugs in the Bazaar API that cause cyclic references and hence some
> > memory not to be freed. Every time my email tool sends an email it seems
> > to loose a bit of memory. I'm not sure how to debug this as I am fairly
> > new to Python.
> >
> > Of course it may be the way I'm using the API that is wrong. If anyone
> > can offer hints on possible gotchas in the Bazaar API that could lead to
> > this I would be very grateful.
> >
> > Cheers,
> >
> > Nick
>
> There was a recent patch from Michael Hudson, I believe, which found a
> reference cycle from LockableFiles (which has a __del__ and thus can't
> be cyclically gc'd), and moved the __del__ into a helper.
>
> We rarely use __del__, so even with a ref cycle the python gc can
> usually clean things up. Using a grep, the ones I find are:
>
> bzrlib/atomicfile.py:124:    def __del__(self):
> bzrlib/lock.py:135:    def __del__(self):
> bzrlib/lockable_files.py:112:    def __del__(self):
> bzrlib/smart/medium.py:655:    def __del__(self):
> bzrlib/transport/memory.py:292:    def __del__(self):
> bzrlib/transport/sftp.py:119:    def __del__(self):
>
>
> For memory and sftp, they are lock clases, which are rarely used today
> (there were only for pre 0.8.2 format branches). And 'memory' is only
> used in the test suite.
>
> Atomicfile shouldn't ever be part of a ref cycle, as it is never really
> given something else to handle (just a file descriptor).
>
> As mentioned, LockableFiles probably needs to be fixed.
>
> The one in 'bzrlib/smart/medium.py' is a bit curious. As that does
> maintain stuff like "_request". I don't know whether there are cycles or
> not, just that it is a more involved class, and thus more likely to run
> into problems.
>
> Anyway, just merging Michael's patch should probably be enough.
>
> John
> =:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090322/fe05929a/attachment.pgp