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

Re: SVN::Client -- why does this leak?

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-11-09 23:42:52 CET

On 11/9/06, Nik Clayton <nik@ngo.org.uk> wrote:
> Hi,
>
> I've just spent some time tracking down a memory leak in some code that uses
> SVN::Client.
>
> Attached is a test that demonstrates the problem. It boils down to this:
>
> sub run {
> my $ctx = SVN::Client->new();
> my $pool = SVN::Pool->new_default();
> my $r = run_cmd($ctx);
> $pool->clear();
>
> return $r;
> }
>
> That leaks memory. Specifically, it leaks at the first line. If the first
> two lines are swapped around:
>
> my $pool = SVN::Pool->new_default();
> my $ctx = SVN::Client->new();
>
> ...
>
> There's no leak.
>
> My problem is that I don't understand why. I've read the pool usage
> conventions section in hacking.html, and the SVN::Pool section in SVN::Core,
> and I thought that since $ctx is going to drop out of scope at the end of
> run() it's going to be automatically garbage collected, and any pool it
> might have created will be cleaned up.

The problem is that since you're creating the $ctx before the pool
it's allocated in whatever the default pool is at the time (probably
the global pool), and thus the underlying svn_client_ctx_t will not be
cleaned up until the global pool is cleared. If you reverse the two
statements the $ctx gets created inside your new pool, so it gets
cleaned up when your clear() gets run. Actually, even without the
clear() it'd still get cleaned up when $pool fell out of scope.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 9 23:43:08 2006

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.