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

Re: possible file/dir handle leaks

From: Steve King <ichselbst_at_gmx.ch>
Date: 2003-12-16 21:57:55 CET

mark benedetto king wrote:

> These functions both create temporary files in a pool. This means
> that when the pool is cleared, the handles are closed. So these
> functions do not technically leak handles, in and of themselves.
> However, it is possible that in some cases the pool lifetimes are
> longer than they should be:
> It looks like SVNStatus::GetStatus() and SVNStatus::GetFirstFileStatus()
> do not immediately clear their pools, rather they use a pool with the
> lifetime of the SVNStatus object (it is a member variable). Could
> it be that the SVNStatus object is not getting deleted immediately?

Yes, that pool isn't destroyed immediately in SVNStatus::GetStatus() and
SVNStatus::GetFirstFileStatus() but only when the SVNStatus object
is destroyed.

I don't think that's the reason for the lock Lübbe describes since
he got the lock even if he has only one file showing in explorer.
And SVNStatus::GetStatus() is used in the shell extension part only
for folders, not single files. For single files a new pool is created
and then a call to svn_client_status() is made - that pool is destroyed
immediately after the call.

But I think I'll try changing my code so that the pool in SVNStatus
can be destroyed and recreated on request.
I hope that will help.

Thanks for your code review and your time.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 16 22:00:01 2003

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

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