[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Possible memory leak in TSVNCache

From: Peter McNab <mcnab_p_at_melbpc.org.au>
Date: 2006-02-07 07:12:41 CET

Stefan Küng wrote:
> Peter McNab wrote:
>
>> TortoiseSVN 1.4.0, Build 5629 - 32 Bit -dev & Subversion 1.3.0,
>> Win2K dual core CPU box.
>>
>> Explore to drive with revisioned folder.
>> TSVNCache crawls.
>> Memory usage climbs as expected.
>> Browse back to MyComputer view.
>>
>> Repeat above process to the same drive as before.
>> Memory usage climbs some more.
>>
>> Repeat above process to the same drive as before.
>> Memory usage climbs some more.
>>
>> Select whitespace in WC.
>> Press F5 .
>>
>> Repeat above process to the same drive as before.
>> Memory usage does not climb this time.
>
> If the memory use doesn't climb too much, then I guess that additional
> memory used is due to some more directories added to the cache (due to
> change notifications).
>
>> Did some testing using a USB removable drive, marvelous thing really.
>>
>> Connected drive and Windows autorun feature pops up an explorer view
>> of first partition.
>> Selecting and moving Explorer vertical scrollbar prompts TSVNCache to
>> crawl newly revealed folders.
>> In TaskManager the cache memory usage climbs a bit.
>> Use windows "Unplug" process and note that cache memory usage does
>> not decrease as indicated by TaskManager.
>>
>> Repeat above process.
>> Memory usage climbs some more but not a lot in % terms.
>>
>> Repeat above process
>> Memory usage climbs some more but not a lot in % terms.
>>
>> Copy a WC onto the USB drive.
>> Memory usage climbs some more but not a lot in % terms.
>> Delete WC. (7000+ files, 1300+ Folders)
>> Memory usage indicated in TaskManager does not decrease.
>
> I've seen that too. But that's expected: Windows doesn't really free
> memory which a process frees, it waits until there's no more memory
> available for other processes or if windows is idle. That's because
> reallocating/freeing memory takes some time (windows has to move
> around memory blocks for that).
>
>> Memory allocated did not rise above 19MB.
>> There still appears to be a small, but less threatening leak still
>> occurring. Sorry I cannot be more specific.
>
> I've added a tooltip for the trayicon in revision 5641 which shows the
> number of cached directories. Maybe that helps to find out where/if
> there's a memory leak.
>
Excellent, better idea than mine too.

OK. Did some more testing with r5644 and the tooltip with interesting
results.

After a re-boot the cache crawls to completion and I see it showing 3250
Cached Directories.
Explorer has not been opened at this point.
TSVNCache memory used as shown by Process Explorer was sitting at 11728k.
TSVNCacheWindow shows no further crawling activity from this point on.
To stimulate some disk activity, run ClamAv on C: drive only, which
contains predominantly Windows installed files, (D: gets everything
else, TortoiseSVN included, E: contains active WCs and lots of non
revisioned stuff).

ClamAV runs to completion and pronounces it checked 2152 directories
with just a handful it couldn't open.
Meanwhile, Process Explorer now shows TSVNCache is using approx 50Mb memory.
ToolTip tells us Cached Directories 94635.
TSVNCacheWindow has not crawled during the ClamAV activity but is still
responsive as shown when open Explorer and navigate.

One conjecture I have is that maybe compressed files are being opened
into a temporary folder for scanning by ClamAV but the entries are not
being removed from the cache when the temp file/folder is destroyed.

Anyway, something for you to mull over.
ClamAV is an open source antivirus project on SourceForge for those who
did not know.

Rgds
Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Feb 7 07:12:57 2006

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.