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

Re: Suspected Memory Leak for merge

From: Brian Buesker <bbuesker_at_qualcomm.com>
Date: 2005-07-14 01:57:08 CEST

John Szakmeister wrote:

>Can you change that last part to be:
> my $subpool = SVN::Pool->new_default;
> for my $i ( 1 .. $n ) {
> $subpool->clear;
> $client->merge (..., $subpool);
> }
Ok, I tried doing that and now the script exits at the merge with an
exit status of 2. The merge is not done at all. No error message is
given though. Am I just doing something stupid? Sorry if it is something
stupid, but I haven't been using pools at all in my scripts.

BTW, if I print out the value of $subpool before the merge, it seems to
be valid (SVN::Pool=REF(0x995fc28)).

Here's my exact code with the URLs removed:

#!/usr/bin/perl -w

use SVN::Client;

my $client = new SVN::Client ( auth => [SVN::Client::get_simple_provider(),

my $subpool = SVN::Pool->new_default;

for my $i ( 1 .. 25 ) {
    print STDERR "Merging in $i\n";

    $subpool->clear ();

    # testing memory usage when create new client each time
    $client->merge ($url1, 'HEAD', $url2, 'HEAD', $wc, 1, 1, 0, 0,

    print STDERR "Merging in $i done\n";

>Some of these client functions aren't as well behaved as they probably
>should be. They make allocations of out the pool passed to them, but we
>don't clear the pool. We should probably be using a subpool for
>temporary allocations in the svn_client functions, and only using pool
>parameter for data that needs to last longer.
>BTW, is there some way you can narrow down what caused the segfault with
>the property merge? I'd like to make that problem go away too.
I believe the merge that it failed on was one which added a new
directory which has a property set on it. Does that help at all?


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 14 01:58:35 2005

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

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