httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: Parsers test eats all the memory
Date Thu, 13 Jan 2005 00:47:36 GMT
Stas Bekman wrote:
> Stas Bekman wrote:
>> Max Kellermann wrote:
>>> On 2005/01/13 00:24, Stas Bekman <> wrote:
>>>>> I changed that to two apr_bucket_brigade_t* variables in my patch.
>>>> could you please repost this particular patch?
>>> That's part of my "lets kill void*env" patch I posted an hour ago. I
>>> havn't made a separate patch of that fix. The old version worked well
>>> for me (512MB+512MB here), therefore I thought that fix was not
>>> important.
>>> Can you apply my patchset, and report if that fixes your problem?
>>> I just don't think that's the problem here, because my machine has
>>> less RAM than yours.
>> applied it and the problem is still there. As Joe has correctly 
>> identified the reason is that I have libapr compiled with 
>> --enable-pool-debug and/or APR_BUCKET_DEBUG.
> I'm trying to rewrite the test to use sub-pools, so the memory is freed 
> more often, but it seems that there are some leaks, so even when 
> reducing the test to a very minimum, just a plain
>   apr_brigade_create(sp, apr_bucket_alloc_create(sp));
> leaks like crazy. so i'm still looking at it.

This consumes 259MB:

static void parse_multipart(CuTest *tc)
     apr_status_t rv;
     apr_size_t i, j;

     for (j = 0; j <= 319; ++j) {
         fprintf(stderr, "LEN %d\n", j);

         for (i = 0; i <= 100; ++i) {
             apr_bucket_brigade *bb;
             apr_pool_t *sp;

             apr_pool_create(&sp, NULL);

             bb = apr_brigade_create(sp, apr_bucket_alloc_create(sp));


Notice that if I reduce the external loop to 100 instead of 319, I get 
only 89MB used. So there is definitely a leak somewhere. It has nothing to 
do with debug functionality enabled. The latter seem to just expose it.

Unless the leak happens only in the debug-enabled version of pool 
functions, i.e. apr_pool_destroy doesn't free the memory. I suspect that 
this is the case. going to look at the apr source code after dinner.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message