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

Re: mod_dav/mod_dav_svn PROPFINDS.

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-07-01 22:39:19 CEST

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

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.


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

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.