[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: Karl Fogel <kfogel_at_red-bean.com>
Date: Tue, 19 Aug 2008 10:48:20 -0400

"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 "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?

(And can you script your recipe? I know it takes time, but it saves N
people time too... :-) ).

Thanks,
-Karl

---------------------------------------------------------------------
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-19 16:48:38 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.