Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
> > I'm specifically looking at subversion/mod_dav_svn.c:1963:
> >
> > /* fetch this collection's children */
> > /* ### shall we worry about filling params->pool? */
> > serr = svn_fs_dir_entries(&children, ctx->info.root.root,
> > ctx->info.repos_path, params->pool);
Meant repos.c, by the way, not mod_dav_svn.c.
> > If we had svn blame, we could figure out who added the ### comment
> > and I believe whomever said that is right.
> >
> > Before calling this function, I think a subpool needs to be
> > created and then delete it as we exit this function. This will mean
> > that the pool will only grow to the depth of the recursive tree, but
> > no more than that rather than the unbounded growth we have now.
> >
> > [...]
>
> Unfortunately no. Sander and I tried just such a patch, and it helped, but
> did not solve the problem. That is, is reduced memory usage from 700MB to
> 400, but obviously that is still too high.
Hmmm. I would be surprised if that were the fix anyway. Usually a
caller should not be creating a subpool for one function call. Maybe
there are rare circumstances where it's justified -- but then, those
are the sorts of circumstances where it would be even *more* justified
for the called function to create and free its own subpool internally!
Rather, callers should use clearable subpools for unbounded loops. I
mean loops where the number of iterations is not constant, but is
dependent on some run-time factor, such as the number of entries in a
directory.
So, I wonder if the real problem could be the loop immediately beneath
the above-quoted code, the loop that begins:
/* iterate over the children in this collection */
for (hi = apr_hash_first(params->pool, children); hi; hi = apr_hash_next(hi))
{
... do various stuff, including at least one more use of
params->pool, hint hint :-) ...
}
Even if subpool'ing that loop doesn't solve the problem, it is
probably still a good idea.
But Ben recalls Greg Stein saying that this might actually be a pool
usage problem in mod_dav itself, so changes in mod_dav_svn may or may
not be part of a solution. Dunno, back to you.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 1 22:48:23 2002