I just got a bug report that that the rewrite of ap_get_client_block() has
introduced a memory leak. Problem is observed when putting a large file to
the server via webdav. Replacing the 2.0.40 implementation with the 2.0.39
implementation (on a 2.0.40 code base) eliminates the problem. I do not
On Wed, Sep 04, 2002 at 05:48:13PM -0400, Bill Stoddard wrote:
I just got a bug report that that the rewrite of ap_get_client_block() has
introduced a memory leak. Problem is observed when putting a large file to
the server via webdav. Replacing the 2.0.40 implementation with the 2.0.39
On Wed, Sep 04, 2002 at 02:53:53PM -0700, Justin Erenkrantz wrote:
On Wed, Sep 04, 2002 at 05:48:13PM -0400, Bill Stoddard wrote:
I just got a bug report that that the rewrite of ap_get_client_block() has
introduced a memory leak. Problem is observed when putting a large file to
the
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.
You know... I bet this will also solve the 'svn import'
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
On Wed, 4 Sep 2002, Greg Stein wrote:
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
On Wed, Sep 04, 2002 at 10:11:13PM -0400, Cliff Woolley wrote:
on some bucket that you're actually finished with. This could be a
symptom of discarding a brigade that still has buckets in it (since
apr_brigade_destroy() will destroy all the buckets that are in the brigade
at the time of the
On Wed, 4 Sep 2002, Justin Erenkrantz wrote:
Will the buckets/brigade be cleaned up when the request_rec's
pool is destroyed or are do they live as long as the connection
pool?
Buckets live forever until you destroy them.
Brigades live as long as the pool they're in (normally r-pool) and
If you are talking about the memory leak when downloading large files
through a proxy chain, this problem was first observed in version
2.0.39, so it probably isn't the same problem.
Peter.
Bill Stoddard wrote:
I just got a bug report that that the rewrite of ap_get_client_block() has
Peter Van Biesen wrote:
If you are talking about the memory leak when downloading large files
through a proxy chain, this problem was first observed in version
2.0.39, so it probably isn't the same problem.
2.0.39 definitely would have had problems with large requests
due to the way its
Cliff Woolley wrote:
Bottom line: the size of c-bucket_alloc will be based on the max number
of buckets and bucket buffers you've had allocated at one time. The
answer is almost certainly that apr_bucket_destroy() is not being called
on some bucket that you're actually finished with. This
11 matches
Mail list logo
