ID: 31558
Updated by: sniper@php.net
Reported By: jdw at nearlyfreespeech dot net
-Status: Open
+Status: Feedback
Bug Type: Apache related
Operating System: FreeBSD
PHP Version: 4CVS-2005-01-21
New Comment:
Yes it would. We're currently focused on PHP 5 development, and if you
really want stuff get fixed: Try the snapshot.
(if this happens in PHP 5.1-dev too, it's more likely to be fixed also
in the PHP_4_3 branch..)
Previous Comments:
------------------------------------------------------------------------
[2005-05-17 14:11:36] jdw at nearlyfreespeech dot net
Um, as this is a PHP 4 bug, trying a PHP 5 snapshot would not seem to
be appropriate.
------------------------------------------------------------------------
[2005-05-17 12:02:53] sniper@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
------------------------------------------------------------------------
[2005-01-22 06:55:13] jdw at nearlyfreespeech dot net
I also looked at the source code. Without a detailed understanding of
zend_hash_*, it isn't clear that all the per_dir_info malloc() cases in
sapi/apache/mod_php4.c (particularly php_value_handler_ex() ) are being
properly freed by php_destroy_per_dir_info(). That's just a WAG, but
it might be something to look into as a possible cause.
------------------------------------------------------------------------
[2005-01-22 06:48:32] jdw at nearlyfreespeech dot net
This test has been completed. I believe this graph of the results
pretty much speaks for itself:
http://example.nfshost.com/ApacheGracefulMem.png
Results:
- With PHP enabled, "graceful" leak averages 903,000 bytes
- With PHP disabled, "graceful" leak averages 8,900 bytes
- "No PHP" test memory usage *converges* (leaks are front-loaded and
poorly represented by the linear fit -- hard to see because of the
scale of the graph)
- "PHP" test memory usage *diverges* (increases linearly until process
limits intervene)
Methodology:
- Apache 1.3.33
- PHP version php4-STABLE-200501210130
- same Apache binary, same server, same conditions
- same conf file (with "LoadModule php4_module" "php_admin_value" and
"php_value" lines removed for the "No HP" test)
- 200 consecutive "graceful" restarts of Apache process
- considering only "master" process
- no requests issued during test
------------------------------------------------------------------------
[2005-01-21 01:04:16] jdw at nearlyfreespeech dot net
Keep in mind that this is happen in the "master" Apache process, a
context in which no PHP scripts are ever executed. In fact, very
little happens other than parsing config files. That should severely
constrain the influence of libraries & extensions.
Apache obviously won't parse its configs with PHP disabled, and our
customers will (justifiably) riot if we turn it off.
There are quite a large number of PHP-specific conf lines in a
proportional number of files (the reason I suspect our setup is finding
this earlier than the general population), so I'm not sure how feasible
your suggestion is.
But I'm happy to see if I can rig something up on a test server to
explore it. More to follow.
It would be more direct if there were a means to instrument the amount
of memory allocated at start vs. the amount freed at restart.
It would also be handy if there's someone around who can point me in
the right direction as to where in the PHP Apache SAPI code to find the
relevant setup/cleanup code.
Also, I now have a second backtrace, but I am hestitant to post it here
because it's even larger than the first one. It's similar: died on a
"php_admin_value open_basedir" instead of "php_admin_value
max_execution_time."
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/31558
--
Edit this bug report at http://bugs.php.net/?id=31558&edit=1