httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 44948] mod_substitute has a memory leak (not a leak)
Date Tue, 09 Sep 2008 00:18:05 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=44948


Basant Kumar Kukreja <basant.kukreja@sun.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |basant.kukreja@sun.com




--- Comment #5 from Basant Kumar Kukreja <basant.kukreja@sun.com>  2008-09-08 17:18:04
PST ---
I think, there is something missing in our understanding. I also find this
leak.

I configured apache with worker mpm using 1 thread.

Then I generated a large file of 300 mb which have repeatitive substituttion :

httpd.conf snippet :

Alias /testsub/ "/usr/local/apache2/htdocs2/testsub/"
LoadModule substitute_module modules/mod_substitute.so
<Directory "/usr/local/apache2/htdocs2/testsub">
    Options FollowSymLinks
    AllowOverride None
    AddOutputFilter SUBSTITUTE html
    Substitute "s/.*one.*two/1 2/"
</Directory>

After every request, process size increases. I used mdb to find the leak :

CACHE     LEAKED   BUFCTL CALLER
080e9810     173 081d7278 libapr-1.so.0.4.0`allocator_alloc+0x2e3
080e9810       2 081d7020 libapr-1.so.0.4.0`allocator_alloc+0x2e3
------------------------------------------------------------------------
   Total     175 buffers, 1612800 bytes

umem_alloc_9216 leak: 173 buffers, 9216 bytes each, 1594368 bytes total
            ADDR          BUFADDR        TIMESTAMP           THREAD
                            CACHE          LASTLOG         CONTENTS
         81d7278          81da480    3524112f1e797                3
                          80e9810                0                0
                 libumem.so.1`umem_cache_alloc_debug+0x14f
                 libumem.so.1`umem_cache_alloc+0x180
                 libumem.so.1`umem_alloc+0xc5
                 libumem.so.1`malloc+0x27
                 libapr-1.so.0.4.0`allocator_alloc+0x2e3
                 libapr-1.so.0.4.0`apr_pool_create_ex+0x77
                 mod_substitute.so`do_pattmatch+0xbb
                 mod_substitute.so`substitute_filter+0x53b
                 ap_pass_brigade+0x9e
                 default_handler+0x461
                 ap_run_handler+0x51
                 ap_invoke_handler+0x15b
                 ap_process_async_request+0x6a
                 ap_process_request+0x1a
                 ap_process_http_connection+0x8e

If you see the do_pattmatch then the leak is there when it create pool.
    apr_pool_create(&tpool, tmp_pool);

After the end of do_pattmatch, pool is safely deleted.
    apr_pool_destroy(tpool);

The question is why the memory is not recycled properly.

Now when I send a single request, it leaks addtional 165 mallocs

So here is the number of malloc leaks reported by mdb :
Leak after initial few requests : 334
After one more request (of 30m size) : 499 
After one more request (of 30m size) : 663
After 10 more request (of 30m size) : 4313

The above pattern keeps increasing linearly with 164 leaks per request.

Mod_substitute code looks ok to me but because of some reason memory recycle
is not happening properly.

But for sure, it seems to be a real issue.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message