httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 44948] mod_substitute has a memory leak (not a leak)
Date Tue, 09 Sep 2008 00:18:05 GMT

Basant Kumar Kukreja <> changed:

           What    |Removed                     |Added
                 CC|                            |

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

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/
<Directory "/usr/local/apache2/htdocs2/testsub">
    Options FollowSymLinks
    AllowOverride None
    AddOutputFilter SUBSTITUTE html
    Substitute "s/.*one.*two/1 2/"

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

080e9810     173 081d7278`allocator_alloc+0x2e3
080e9810       2 081d7020`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

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.

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:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message