[tahoe-dev] Debugging memory leaks with guppy

[David-Sarah Hopwood]

David-Sarah Hopwood wrote:
> Brian wrote:
>> My suspicion is that the ResponseCache object is living a lot longer
>> than expected, and it's accumulating cached responses from lots and lots
>> of generations ("versions") of the mutable file that contains a
>> directory which is being modified heavily. When you say your test
>> "deleted about 1000 very small files from a single directory", you're
>> really making 1000 sequential changes to the same directory, right? So
>> there will be 1000 mutable file writes to the same file? If my suspicion
>> is right, there will be 1000 different 'verinfos' values (and N times as
>> many keys in self.cache, each of which may have multiple strings in the
>> set, resulting in a large number of strings left around).
>>
>> When I first wrote ResponseCache back during the original Big Mutable
>> File Rewrite (in april-2008), I expected that instances would only stick
>> around for the duration of a mutable-file operation and then be gc'ed,
>> so I didn't worry about ever removing old versions from its cache.
> 
> The SFTP frontend is intended to keep around a reference to a dirnode
> object only as long as there exists at least one open handle to that
> directory on some SFTP connection.

Oh, I've just looked at the code again and seen an exception: while a given
SFTP user is logged in, a dirnode object for the root directory of that
user will be retained.

(This is by design; I've tried to follow the obj-cap programming principle
of using references rather than strings to designate objects for as long
as possible.)

Francois: does it make a difference whether the directory being modified is
the root directory or a subdirectory?

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20101022/613a1ee2/attachment.pgp>