Re: Source of memory leak in mod_proxy?

On Wed, Sep 04, 2002 at 05:24:07PM -0700, Justin Erenkrantz wrote:
> On Wed, Sep 04, 2002 at 05:17:29PM -0700, Greg Stein wrote:
> >
> > Yup. On the error exits, too.
>
> Hmm. On the error exits, shouldn't the request pool get cleaned up
> right after that? But, for the successful cases, it makes sense to
> cleanup.

Are you sure about that? Will ever caller to ap_get_client_block() exit and
clean up the request pool? :-)

> > You know... I bet this will also solve the 'svn import' problem that we've
> > been seeing lately. In that case, the server memory just skyrockets,
> > proportional to the amount of data imported. This would do it.
>
> Hmm. Why wouldn't they be cleaned up when the request pool
> is cleaned up? I wonder if its something else there. As,
> svn import is multiple-request based rather than one large
> commit, right? So, r->pool would be cleaned up on each request
> and the brigade freed.
>
> Or, maybe I'm missing something... -- justin

Oh... right. Hrm. But in that case, then SVN shouldn't be accumulating
memory either. "multiple requests"

Hey... look at this line:

    bb = apr_brigade_create(r->pool, r->connection->bucket_alloc);

Does that allocator somehow use connection memory? Maybe we have some kind
of leak between the request-based brigade and the connection-based
allocator?
[ I don't know enough about the bucket allocator stuff ]

Alternatively, we might also be seeing some kind of fragmentation in the
allocator. Note that we might not be seeing the problem in other scenarios
simply because we're doing PUTs here (and most testing doesn't), and that
we're dealing with heap memory as opposed to FILE or PIPE buckets.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org