httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
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 <stas@stason.org> 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));
             apr_brigade_destroy(bb);

             apr_pool_destroy(sp);
         }
     }
     sleep(10);
}

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
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Mime
View raw message