--On Friday, January 10, 2003 4:32 PM -0500 Michael Price
<mprice@atl.lmco.com> wrote:
> $ ~/local/tmp> svnadmin create repo
> $ ~/local/tmp> svn co file://`pwd`/repo wc
> Checked out revision 0.
> $ ~/local/tmp> cd wc
> $ ~/local/tmp/wc> for file1 in 0 1 2 3 4 5 6 7 8 9; do
>> for file2 in 0 1 2 3 4 5 6 7 8 9; do
>> for file3 in 0 1 2 3 4 5 6 7 8 9; do
>> echo "too-slow" > $file1.$file2.$file3
>> done; done; done
> $ ~/local/tmp/wc> svn add ?.?.?
> [removed output]
> $ ~/local/tmp/wc> svn commit -m "stuff"
> [removed output]
> $ ~/local/tmp/wc> svn update
> Abort (core dumped)
Well, it's probably dumping core because of a ulimit memory ceiling.
(Runs fine here albeit with excessive memory.)
The reason for the memory leak is again incorrect pool usage in
libsvn_fs. This is also the Issue #773 culprit. Stuff is being
allocated from trail->pool when there isn't a need to keep it around
permanently. (trail->pool is only meant for allocation of things
that must live longer than the associated BDB transaction.)
I really think we ought to rethink almost all of the pool usage in
libsvn_fs. The problem is that I don't have the time to really
address this. I could start a branch and slowly work my way through
this, but I'm afraid Karl and C-Mike aren't yet done tweaking
libsvn_fs for their own stuff. That means that I'm going to be
widely divergent from the trunk real quickly if this isn't
synchronized.
I'll try to whip up a patch that minimizes the memory usage of this
code path, but I'm running into libsvn_fs way more than I'd like to.
I think it indicates brokenness we need to step back and consider the
right fix. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 11 00:49:58 2003