https://issues.apache.org/bugzilla/show_bug.cgi?id=44948
Basant Kumar Kukreja <[EMAIL PROTECTED]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
--- Comment #5 from Basant Kumar Kukreja <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
