> -----Original Message-----
> From: Daniel Rall [mailto:dlr@collab.net]
> Sent: Wednesday, June 06, 2007 8:33 PM
> To: Ben Collins-Sussman
> Cc: dev
> Subject: Re: big memleak in svn 1.5
>
> On Wed, 06 Jun 2007, Daniel Rall wrote:
>
> > On Wed, 06 Jun 2007, Ben Collins-Sussman wrote:
<snip>
> > The main differences are for:
> >
> > a) Eliding of merge info in the WC
> > b) Depth argument handling
> > c) Preserved file extension handling
> >
> > (b) isn't obviously suspect in this function, but there's potential
> > for a leak buried in the changes to the reporter code. (c)
> is fairly
> > simple, and also seems pretty unlikely.
> >
> > WRT (a), I notice two potential scalability issues, the second
> > somewhat dependent upon the first:
> >
> > 1) children_with_mergeinfo_hash could potentially grow to be large.
> > 2) We iterate over children with merge info, but don't use
> a sub-pool.
> >
> > I'm attaching a patch for #2, but I don't think we can
> easily fix #1.
> > Assuming Google's tree doesn't have much/any merge info, I
> doubt this
> > will have much impact on the memory footprint, unless the leak is
> > buried under svn_client__elide_mergeinfo().
>
> Patch wasn't quite right, attaching a corrected revision.
As we discussed on IRC this patch isn't going to solve this particular
memory leak, but it might solve some future ones where there actually
are a lot of paths under the update target with mergeinfo.
Added similar code for switch.c:svn_client__switch_internal and
committed r25322.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 7 18:23:55 2007