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

Re: File descriptor leak of rep-cache.db in 1.6.x

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Thu, 03 Jun 2010 16:45:34 +0100

Dan Villiom Podlaski Christiansen <danchr_at_gmail.com> writes:

> The bug is somewhat subtle, and the circumstances causing it are
> fairly complex. In the cause of running a test suite, we open
> repositories repeatedly using the ‘file’ protocol, log their history
> and fetch the contents of all revisions. This will fail after about
> a hundred tests, having exhausted file descriptors. Inspecting the
> output of ‘lsof’ on the process, there are 216 open references to
> ‘rep-cache.db’ files.

Issue 3506 has changed the way the rep-cache is written:

http://subversion.tigris.org/issues/show_bug.cgi?id=3506

The changes are not in 1.6 yet:

http://svn.apache.org/repos/asf/subversion/branches/1.6.x-issue3506/

> As mentioned, the circumstances causing the bug are fairly
> complex. I see this in hgsubversion,[1] a Mercurial plugin for
> Subversion interoperability. Both Mercurial and hgsubversion are
> written in Python, and historically, hgsubversion has used the SWIG
> bindings for Subversion. Unfortunately, we have found the SWIG
> bindings to leak like a sieve; it is not uncommon that converting
> large repositories uses several gigabytes of memory or even exhaust
> address space in a 32-bit environment.

If converting a repository is a bit like "svnadmin dump" then it may
not be SWIG, you might be seeing issue 3593:

http://subversion.tigris.org/issues/show_bug.cgi?id=3593

-- 
Philip
Received on 2010-06-03 17:46:18 CEST

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.