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

Re: Memory leak with 1.6.x clients

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 20 May 2009 21:45:12 +0100

On Wed, May 20, 2009 at 01:05:26PM -0700, Brian Osmus wrote:
> Link: themeData
> Link: colorSchemeMapping
> A new Memory leak created in 1.6..x client versions. When trying to commit
> ~33 K files the SVN client allocates approximately 0.5MB of memory for
> each file this quickly depletes the memory and swap space. As a result,
> the OS kills the SVN client. Tried to do the commit several times with
> 1.6.1 client then attempted with 1.6.2 client giving the same result. In
> case the sandbox had become corrupted, created a new sandbox using a 1.6.2
> client and applied all the changes to it, again with the same result. Then
> ran the python script to convert the local copy for the 1.5.4 client. The
> commit worked with the 1.5.4 client.
> I did find a post about this same issue under the usera**s forum and
> somebody pointed bug #1964 which has been open since 2004 but I was able
> to commit my changes without error using 1.5.4 with the same exact client
> configuration, so it stands to reason that this is a new bug. This is not
> a repeat of another bug report.

It can still be the very same bug.
Maybe what you are seeing is just issue #1964 which has gotten
more visible in 1.6 because Subversion is now doing more than
it used to do in 1.5? I.e. the extra use of memory is legitimate?

Note that I'm not trying to explain away the problem.
I'm not excluding the possibility of an accidental memory leak,
and I concur that there is a problem, i.e. issue #1964 should
really be fixed in the long term because we shouldn't just crash
when adding a huge amount of files. That is really bad behaviour.

However, does using "svn import" instead of "svn add" work for you?
This is an important question! Knowing whether svn import can still
be used as a workaround is important because if it cannot be used as
a workaround anymore, we have a serious regression. If it can still
be used, the only possible regression is that issue #1964 is now easier
to encounter than before.

> To reproduce this issue create a new repository and check in an older
> Linux Kernel 2.6 once that is done get a newer Linux Kernel 2.6 and merge
> that with what you checked in. Then do the svn commit and watch top.
> Notice the memory use for the process increasing rapidly as the dots are
> displayed by the process. In my case, OOM killed the process with a -9.

How are you doing this? Are you adding the entire Linux source tree to
the working copy and then try to commit it? If so, this is a really a
use case where, according to issue #1964, svn import should be used
instead of svn add, *by design* (as bad as the design may be).
I am surprised that this works with 1.5.x, even.

Received on 2009-05-20 22:45:31 CEST

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