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

Re: Memory leak in svn_ra_local__get_file() for symlinks

From: Ph. Marek <philipp.marek_at_bmlv.gv.at>
Date: Thu, 21 Aug 2008 07:36:02 +0200

Hello Karl,

thank you for your answer.

On Dienstag, 19. August 2008, Karl Fogel wrote:
> "Ph. Marek" <philipp.marek_at_bmlv.gv.at> writes:
> > I found a (kind of) memory leak in svn_ra_get_file() for file://-urls,
> > with 1.5.1 libraries, reproduceable with "svn cat", too.
> >
> > It shows as an allocation of about 500kB for this call; for a svn+ssh://
> > url it's only about 26k.
> >
> > Reproduction recipe (with plain binaries, without symbols):
> > * a fsfs repository, accessible via file://, with a symlink in it
> > (in my tests in /trunk/subdir/symlink), with data of about 60 bytes.
> > * svn_ra_get_file(); for me into a svn_stringbuf_t, but a plain
> > "svn cat" (which does stream to disk, I think) shows that too.
> > * "gdb --args svn cat file:///repos/path/trunk/dir/symlink"
> > * Set a breakpoint on "svn_ra_get_file()"
> > * Start the svn process
> > * When the breakpoint is hit, look at the process' size
> > * Continue this function with "n"; gdb stops at the end
> > * Look at the size again - +500kB.
> >
> > That's on debian, i686; if you need any more details just ask.
> If you cat multiple files in the same client session, does it grow by
> 500kb each time, or is it just a constant overhead to the first time?
I had a loop over the items in a directory; if they are symlinks, I fetch the
One user had to kill the process after 1GB of RAM was eaten and swap was used
heavily (for /usr/lib and/or the X11 fonts, not sure - but many symlinks in a
single directory).

> > I "fixed" that by creating a new child pool, and destroying that directly
> > after the svn_ra_get_file() - but needing ~500kB for 80 byte data is a
> > bit much, isn't it?
> Can you show that patch?
The patch is in FSVS - apart from the subpool for each directory I made a new
pool for each call to svn_ra_get_file().

No fix for subversion yet.

> (And can you script your recipe? I know it takes time, but it saves N
> people time too... :-) ).
I'm on another machine currently; but something like this should work:


  cd /tmp
  test -d $REPOS && rm -fr $REPOS
  svnadmin create $REPOS
  test -d $WC && rm -fr $WC
  svn co file:///tmp/$REPOS $WC
  cd $WC
  ln -s aaaaaaaaaaaaaaaaaaa/aaaaaaaaaaa/aaaaaaaaaaaaaa/aaaaaaaaaa/aaaaaa bb
  svn add bb
  svn ci -m1
  gdb --args svn cat file:///tmp/$REPOS/bb

And GDB needs this input:
  b svn_ra_get_file
        (acknowledge question about future symbol resolution with "Y")
  shell cat /proc/`pidof svn`/status | grep Vm
  shell cat /proc/`pidof svn`/status | grep Vm

But I have to admit that here I can't reproduce the problem. This is a debian
unstable i686, with 1.5.1; if the difference lies in the apr libraries or in
the 64bit/32bit distinction I can't say ATM.
Here I have
        libaprutil1 1.2.12+dfsg-7
        libapr1 1.2.12-4
        libapr0 2.0.55-4.2
        subversion 1.5.1dfsg1-1

If somebody could reproduce that (or can't), we might be able to find the
misbehaving bit.



To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-21 07:36: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.