Bug #50519 [Com]: segfault in garbage collection when using set_error_handler and DomDocument
Edit report at https://bugs.php.net/bug.php?id=50519edit=1 ID: 50519 Comment by: mplomer at gmx dot de Reported by:robin dot kunde at gmail dot com Summary:segfault in garbage collection when using set_error_handler and DomDocument Status: Closed Type: Bug Package:Reproducible crash Operating System: * PHP Version:5.3, 6 Assigned To:dmitry Block user comment: N Private report: N New Comment: Hi ... we currently reproduced the segfault in the same line (zend_gc.c - pz = *(zval**)p-pData;: - PHP 5.4.7 - Very long running and memory intensive command line script - Always reproducable GDB-Backtrace: Program terminated with signal 11, Segmentation fault. #0 0x006e7576 in zval_mark_grey (pz=0x2c36d00) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_gc.c:425 425 pz = *(zval**)p-pData; (gdb) bt #0 0x006e7576 in zval_mark_grey (pz=0x2c36d00) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_gc.c:425 #1 0x006e84ce in gc_collect_cycles () at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_gc.c:471 #2 0x006e8864 in gc_zval_possible_root (zv=0x2c36d00) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_gc.c:166 #3 0x006d5dbb in zend_hash_destroy (ht=0x1811dcb8) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_hash.c:560 #4 0x006c8179 in _zval_dtor_func (zvalue=0x189270f0) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_variables.c:43 #5 0x006bb29d in _zval_ptr_dtor (zval_ptr=0x2ac8cc0) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_variables.h:35 #6 0x006d7f28 in _zend_hash_add_or_update (ht=0x7f27eb1873b0, arKey=0x18cb3870 instruments, nKeyLength=12, pData=0x1, nDataSize=415173616, pDest=0x0, flag=6061480) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_hash.c:234 #7 0x005c7da8 in T.292 (ht=0x2c36d00, arKey=0x7fff0da8a360 \370\025\016\353'\177, nKeyLength=2, pData=0x7f27eb1a1200) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_hash.h:351 #8 0x005ccd66 in spl_array_write_dimension_ex (check_inherited=415524600, object=0x18c466f8, offset=0x18bf5238, value=0x6a624f7961727241) at /usr/src/php5.4/source/php5-5.4.7/ext/spl/spl_array.c:461 #9 0x005cd3b6 in zim_spl_Array_offsetSet (ht=46361856, return_value=0x7fff0da8a360, return_value_ptr=0x2, this_ptr=0x7f27eb1874f0, return_value_used=415173616) at /usr/src/php5.4/source/php5-5.4.7/ext/spl/spl_array.c:713 #10 0x7f280964206b in xdebug_execute_internal () from /usr/lib/php5/20100525/xdebug.so #11 0x00745806 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f280da03108) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_vm_execute.h:644 #12 0x00732978 in execute (op_array=0x7f27eb19e648) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_vm_execute.h:410 #13 0x7f2809642509 in xdebug_execute () from /usr/lib/php5/20100525/xdebug.so #14 0x00745b03 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f280da01e40) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_vm_execute.h:669 #15 0x00732978 in execute (op_array=0x33d0240) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_vm_execute.h:410 ... Previous Comments: [2010-02-03 18:07:26] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionrevision=294427 Log: - Fixed bug #50519 (segfault in garbage collection when using set_error_handler an.. [2010-01-25 16:46:55] s...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revisionrevision=294000 Log: merge -r292624: Fixed bug #50519 (segfault in garbage collection when using set_error_handler and DomDocument (dmitry) [2010-01-11 10:07:52] dmi...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2010-01-11 10:07:10] s...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revisionrevision=293400 Log: Fixed bug #50519 (segfault in garbage collection when using set_error_handler and DomDocument) [2009-12-31 18:21:00] j...@php.net Well, you fixed it only with --enable-debug being used? :) The remainder of the comments for this report are too long. To view the rest
[PHP-BUG] Bug #60509 [NEW]: pcntl_signal doesn't decrease ref-count of old handler when setting SIG_DFL
From:
Operating system: Debian Squeeze
PHP version: 5.3.8
Package: PCNTL related
Bug Type: Bug
Bug description:pcntl_signal doesn't decrease ref-count of old handler when
setting SIG_DFL
Description:
When overwriting an old signal handler (that references $this for
example) with SIG_DFL, the reference counter on $this is not decreased, so
when unsetting the object, it cannot be freed.
My current workaround: When overwriting the signal handler with an empty
function before (function() {}), the ref-count is correctly decreased
(WTF?!), and the instance is immediately freed, when unsetting the object.
Test script:
---
class Test {
public function __construct() {
pcntl_signal(SIGUSR1, array($this, 'signalHandler'), false);
//pcntl_signal(SIGUSR1, function() {}); // destruct works correctly
when commenting in
pcntl_signal(SIGUSR1, SIG_DFL);
}
public function signalHandler() {
}
public function __destruct() {
echo '__destruct' . PHP_EOL;
}
}
$test = new Test();
echo 'unsetting' . PHP_EOL;
unset($test);
echo 'end' . PHP_EOL;
Expected result:
unsetting
__destruct
end
Actual result:
--
unsetting
end
__destruct
--
Edit bug report at https://bugs.php.net/bug.php?id=60509edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60509r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60509r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60509r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60509r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60509r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60509r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60509r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60509r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60509r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60509r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60509r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60509r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60509r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60509r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60509r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60509r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60509r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60509r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60509r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60509r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60509r=mysqlcfg
Req #52569 [Ana]: Implement ondemand process-manager (to allow zero children)
Edit report at http://bugs.php.net/bug.php?id=52569edit=1 ID: 52569 User updated by:mplomer at gmx dot de Reported by:mplomer at gmx dot de Summary:Implement ondemand process-manager (to allow zero children) Status: Analyzed Type: Feature/Change Request Package:FPM related PHP Version:5.3.3 Assigned To:fat Block user comment: N Private report: N New Comment: Unfortunately not, as libevent was removed from FPM in PHP 5.3.4, the patch has to be ported to the new simple mini event library. If you are interested to do the port and you are familar with C you are welcome, and I can give you a quick starting point. Previous Comments: [2011-06-11 10:22:33] denoc at gmx dot de I tried to patch php5-5.3.5 with the last offered patch, but it did not work. Does a patch against the current version exist? Thanks [2010-11-12 02:30:36] luca at fantacast dot it Just to be clear, I'm not advocating this solution, just contemplating the implications. Hand built disable_functions by sysadmins is not realistic and centralized maintenance in FPM code (if at all possible) would still require work and be prone to error. Running as root is very bad security wise and makes almost every other security check useless in case of a bug. [2010-11-12 01:53:01] f...@php.net However this could be easily prevented by using disable_functions to prevent these and other potentially harmful functions from being called (system, exec, etc) which could be used to achieve the same goal and are not desirable in a shared hosting environment anyway. - it's very complex to do. - you have no guarantee that nothing will be forgotten (until a security hole is found) - you have to maintain this security layer over the time, adding new functions, ... - If the sysadm have to list the functions to be forgotten, it will forget some (by following a buggy how-to -- which are all over the Internet btw) Obviously this wouldn't protect against PHP bugs allowing arbitrary code execution, so it only mitigates the potential risk. I'm sorry, but it's not an option to me. There security checks at kernel level which must not be gotten arround by code running from userland (PHP core). [2010-11-12 01:28:55] luca at fantacast dot it Just a thought on the dynamic setuid/setgid/chroot via fastcgi variables exclusion because of security concerns. In the group discussion you pointed out how this opens up the possibility for an attacker to call posix_setuid/posix_setgid in PHP code to get root privileges. However this could be easily prevented by using disable_functions to prevent these and other potentially harmful functions from being called (system, exec, etc) which could be used to achieve the same goal and are not desirable in a shared hosting environment anyway. I guess this and other protections could be even enforced automatically by PHP FPM if dynamic setuid/setgid/chroot via fastcgi variables is requested. Obviously this wouldn't protect against PHP bugs allowing arbitrary code execution, so it only mitigates the potential risk. [2010-09-25 18:26:58] mplomer at gmx dot de Released patch v6 - Updated patch to be compatible with current PHP_5_3 branch (rev 303365) There are no functional changes against v5 Merged (removed) parts which have already been committed: - rev 301886: only one process (for all pools) could be killed by the 'dynamic' process manager - rev 301912: Changed listen.backlog in the FPM configuration file to default to 128 instead of -1 - rev 301913: Add libevent version to the startup debug log in FPM - rev 301925: add 'max children reached' to the FPM status page Changes: - Undo change in config.m4 which has IMHO nothing to do with this patch - Merged listen.backlog part in php-fpm.conf.in from trunk (trunk and 5.3-branch is currently out of sync here!) - (small code beautify) 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/bug.php?id=52569 -- Edit this bug report at http://bugs.php.net/bug.php?id=52569edit=1
Bug #54275 [Com]: Exception thrown in error_handler is swallowed
Edit report at http://bugs.php.net/bug.php?id=54275edit=1
ID: 54275
Comment by: mplomer at gmx dot de
Reported by:v-o-e at gmx dot de
Summary:Exception thrown in error_handler is swallowed
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: all
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
I just downtracked the same problem. Additionally I have noticed that
after the fatal error occours (after throwing the notice, which is
swallowed), the shutdownFunction isn't called at all (tested on PHP
5.3.2).
When not throwing an error in error-handler, shutdownFunction is called
properly.
Previous Comments:
[2011-03-16 16:23:35] v-o-e at gmx dot de
Description:
Exception thrown in error_handler is swallowed if fatal error occurs
after error in same instruction
somewhat related (closed) bugs:
http://bugs.php.net/bug.php?id=36773
http://bugs.php.net/bug.php?id=51463
Test script:
---
function error($code, $message, $file = null, $line = 0) {
echo convert error to exceptionbr\n;
throw new \ErrorException($message, $code, null, $file, $line);
}
function shutdown() {
echo shutdown function calledbr\n;
}
set_error_handler('error');
register_shutdown_function('shutdown');
try {
echo $crypto-compress();
} catch (\Exception $e) {
echo exception catchedbr\n;
}
echo after fatal errorbr\n;
Expected result:
exception should be catched as in (note the @ operator to suppress a
FATAL ERROR!):
function error($code, $message, $file = null, $line = 0) {
echo convert error to exceptionbr\n;
throw new \ErrorException($message, $code, null, $file, $line);
}
function shutdown() {
echo shutdown function calledbr\n;
}
set_error_handler('error');
register_shutdown_function('shutdown');
try {
echo @$crypto-compress();
} catch (\Exception $e) {
echo exception catchedbr\n;
}
echo after fatal errorbr\n;
Actual result:
--
1. Exception thrown in error_handler is swallowed
2. the fatal error after Undefined variable occurs
--
Edit this bug report at http://bugs.php.net/bug.php?id=54275edit=1
Bug #47530 [Com]: Importing objects into document fragments creates bogus default namespace
Edit report at http://bugs.php.net/bug.php?id=47530edit=1
ID: 47530
Comment by: mplomer at gmx dot de
Reported by:sgunderson at bigfoot dot com
Summary:Importing objects into document fragments creates
bogus default namespace
Status: Assigned
Type: Bug
Package:DOM XML related
Operating System: Debian
PHP Version:5.2.9
Assigned To:rrichards
Block user comment: N
Private report: N
New Comment:
This does not only affect DocumentFragments. I had this problem with a
simple importNode() when having multiple default namespaces. Here is a
simplified XML sample:
Reproduce code:
---
?php
$xml = '?xml version=1.0 encoding=utf-8?
feed xmlns=http://www.w3.org/2005/Atom;
div xmlns=http://www.w3.org/1999/xhtml;
pTest-Text/p
/div
/feed';
$dom = new DOMDocument();
$dom-loadXML($xml);
$dom2 = new DOMDocument();
$importedNode = $dom2-importNode($dom-documentElement, true);
$dom2-appendChild($importedNode);
echo $dom2-saveXML();
?
Actual result:
--
?xml version=1.0?
feed xmlns=http://www.w3.org/2005/Atom;
xmlns:default=http://www.w3.org/1999/xhtml;
default:div xmlns=http://www.w3.org/1999/xhtml;
default:pTest-Text/default:p
/default:div
/feed
Previous Comments:
[2009-02-28 14:48:20] sgunderson at bigfoot dot com
Description:
Hi,
When I import a DOM node via a document fragment, suddenly a default
namespace comes out of nowhere (and it's really hard to remove, short of
making my own cloneNode() simulation stripping it).
IIRC PHP4 got this right (although it had lots of other issues), and all
other languages I've tested in (Perl, Python, Ruby) do as well. Note
that the code below doesn't strictly need importNode(), but I cannot
really do with cloneNode() in the real code (it's vastly simplified).
Note: On the surface, this appears to be the same bug as #46185, but I
tested 5.3 CVS (as of 2009-02-28) and it's still there.
Reproduce code:
---
?php
$doc = new DOMDocument;
$doc-loadXML('html xmlns=something xmlns:ns=whateverelement
ns:foo=bar //html');
$root = $doc-documentElement;
$elem = $root-firstChild;
$frag = $doc-createDocumentFragment();
$frag-appendChild($doc-importNode($elem));
$root-appendChild($frag);
print $doc-saveXML();
?
Expected result:
?xml version=1.0?
html xmlns=something xmlns:ns=whateverelement
ns:foo=bar//html
Actual result:
--
?xml version=1.0?
html xmlns=something xmlns:ns=whateverdefault:element
xmlns:default=something xmlns:ns=whatever ns:foo=bar//html
--
Edit this bug report at http://bugs.php.net/bug.php?id=47530edit=1
Req #44164 [Asn]: Handle Content-Length HTTP header when zlib.output_compression active
Edit report at http://bugs.php.net/bug.php?id=44164edit=1
ID: 44164
User updated by:mplomer at gmx dot de
Reported by:mplomer at gmx dot de
Summary:Handle Content-Length HTTP header when
zlib.output_compression active
Status: Assigned
Type: Feature/Change Request
Package:*General Issues
Operating System: *
PHP Version:5.2.5
Assigned To:cataphract
Block user comment: N
New Comment:
In the meantime we do output-compression only via apache. But back to
the problem:
First I thought it would be better to remove the header if present
(buffering output is not an option of course), but it is also an idea to
disable output compression completely, when this header is set (which is
a rare case in our environment, and INHO most php users, too).
Our problem was that Varnish Reverse Proxy was confused by this
inconsistent headers. Both solutions would solve this.
Previous Comments:
[2010-10-23 15:04:29] cataphr...@php.net
I've just been hit by this problem and I'm thinking a better option
would be to disable zlib.output_compression if the Content-Length header
is set. What do you think?
Buffering everything and then calculating the actual length is not
really an option, the output could be several hundred megabytes.
[2008-02-19 11:04:24] mplomer at gmx dot de
Another idea is:
IF the Content-Length header IS set from the script,
THEN buffer the complete output and calculate the correct compressed
Content-Length.
ELSE do nothing (do not add any Content-Length header)
So ob_flush(), flush() will still work if compression is active. (Which
will not work, if we use apache's mod_deflate. This is why
zlib.output_compression is required.)
[2008-02-19 10:48:09] mplomer at gmx dot de
Description:
If you have a big project, where Content-Length header is set on many
places, and then you turn on zlib.output_compression, you will have a
problem, because the original header is still passed through, but it is
invalid now, because it contains the length of the uncompressed data
instead of the compressed data.
This would confuse some HTTP clients, that rely on the
Content-Length.
I think, zlib.output_compression should be completely transparent, so
this issue should be handled in php core.
One solution is, to remove the Content-Length header (if set) in
ob_gzhandler() in ext/zlib/zlib.c:882 (where Content-Encoding: gzip
header is set). If you see a good way to set the Content-Length to the
compressed length, this would be, of course, the best solution, but this
is IMHO only possible, if the entire data is buffered before (or is this
done by ob_gzhandler anyway?).
This would make the various workarounds irrelevant that have to be done
if zlib.output_compression is active and is completely backward
compatible.
Reproduce code:
---
In php.ini:
zlib.output_compression = On
?php
$output = str_repeat('A', 8192);
header('Content-Length: ' . strlen($output));
?
Expected result:
Correct Content-Length header or removed Content-Length header in
response, because the old length is always wrong. Better send no
Content-Length instead a wrong length.
Actual result:
--
The old Content-Length header is sent.
--
Edit this bug report at http://bugs.php.net/bug.php?id=44164edit=1
Bug #52501 [Com]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501edit=1 ID: 52501 Comment by: mplomer at gmx dot de Reported by:marekroman1 at gmail dot com Summary:Misconfigured Sendmail sends PHP-FPM into an infinite loop Status: Feedback Type: Bug Package:FPM related Operating System: DebianLenny2.6.26-2-openvz-amd64 PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: I did some general tests with patch.v7 (apachebench with hitting the limits; increasing and decreasing server load; ...) and I could not detect any errors. But I did not do any more detailed tests. Previous Comments: [2010-10-06 11:36:35] f...@php.net small bug correction. [2010-10-06 11:36:15] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v7.patch Revision: 1286357775 URL: http://bugs.php.net/patch-display.php?bug=52501patch=fpm-nomorelibevent.v7.patchrevision=1286357775 [2010-10-06 02:39:23] f...@php.net Can you please test the updated version of the patch ? I'm waiting for your returns to commit. [2010-10-06 02:37:39] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v6.patch Revision: 1286325458 URL: http://bugs.php.net/patch-display.php?bug=52501patch=fpm-nomorelibevent.v6.patchrevision=1286325458 [2010-10-03 12:35:23] f...@php.net It's a case I didn't care about as it's a first release debug patch. Thx you very much for your tests and comments. ++ Jerome 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/bug.php?id=52501 -- Edit this bug report at http://bugs.php.net/bug.php?id=52501edit=1
Req #52569 [Com]: Implement ondemand process-manager (to allow zero children)
Edit report at http://bugs.php.net/bug.php?id=52569edit=1
ID: 52569
Comment by: mplomer at gmx dot de
Reported by:mplomer at gmx dot de
Summary:Implement ondemand process-manager (to allow zero
children)
Status: Analyzed
Type: Feature/Change Request
Package:FPM related
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
Released patch v6 - Updated patch to be compatible with current PHP_5_3
branch (rev 303365)
There are no functional changes against v5
Merged (removed) parts which have already been committed:
- rev 301886: only one process (for all pools) could be killed by the
'dynamic' process manager
- rev 301912: Changed listen.backlog in the FPM configuration file to
default to 128 instead of -1
- rev 301913: Add libevent version to the startup debug log in FPM
- rev 301925: add 'max children reached' to the FPM status page
Changes:
- Undo change in config.m4 which has IMHO nothing to do with this patch
- Merged listen.backlog part in php-fpm.conf.in from trunk (trunk and
5.3-branch is currently out of sync here!)
- (small code beautify)
Previous Comments:
[2010-09-13 06:27:20] f...@php.net
You should make clean before recompiling with v5 patch.
The v5 patch does not apply on 5.3.3, it applies on the svn PHP5_3_3
branch.
++ Jerome
[2010-09-13 03:30:56] dennisml at conversis dot de
Is v5 of the patch known not to work with fpm in php 5.3.3? When
applying the patch I get the following segfault:
Program received signal SIGSEGV, Segmentation fault.
0x005cf319 in fpm_env_conf_wp (wp=value optimized out)
at /home/dennis/php-5.3.3/sapi/fpm/fpm/fpm_env.c:141
141 if (*kv-value == '$') {
[2010-09-05 20:42:56] f...@php.net
@dennisml at conversis dot de
It's complex to do and security risky. Don't want to mess with that.
[2010-09-04 16:26:06] dennisml at conversis dot de
Since this patch causes the master process to dynamically fork children
on demand I'm wondering if it would be feasible to introduce the
possibility to do setuid()/setgid() calls after the fork to run the
child process with different user id's?
What I'm thinking about is the mass-hosting case that was previously
talked about on the mailinglist. Back then this would have been quite a
bit of work to do but with this patch this should be much easier to
accomplish.
[2010-08-30 10:21:37] mplomer at gmx dot de
Some test results of the ondemand-pm:
General
- Pool has to start with 0 children - OK
- Handling and checking of new config options - OK
Concurrent requests
- Children has to be forked immediately on new requests without delay -
OK
- Idle children has to be killed after pm.process_idle_timeout + 0-1s -
OK
- When there are more than one idle children, kill only one per second
PER POOL - OK
Reaching pm.max_children limit
- No more processes has to be created - OK
- Requests have to wait until one child becomes idle and then get
handled immediately without further delay - OK
- When limit is reached, issue a warning and increase status counter
(and do this only once) - OK:
Aug 28 13:39:41.537174 [WARNING] pid 27540,
fpm_pctl_on_socket_accept(), line 507: [pool www] server reached
max_children setting (10), consider raising it
- Warning is re-issued after children count decreases and hit the limit
again - OK
CPU burns
- When reaching max_children limit, pause libevent callback and reenable
it in the maintenance routine, to avoid CPU burns - OK
- When children takes too long to accept() the request, avoid CPU burn -
NOTOK
- happens sometimes (in praxis only sometimes after forking) - to
reproduce add an usleep(5) in children's code after fork(), or
apachebench with ~200 concurrent requests :-)
- You get a lot of: fpm_pctl_on_socket_accept(), line 502: [pool www]
fpm_pctl_on_socket_accept() called
- It's not a big problem, because this doesn't take much time (in one
rare case it took ~90ms on my machine), but it's not nice, especially
when the server is flooded with requests
- one idea:
- do not re-enable event-callback in fpm_pctl_on_socket_accept
- send an event from children just after accept() to parent process
- re-enable event-callback in parent process, when it receives this
event from children
- in case of an error it is re-enabled in the maintainance routine
after max 1s, which is IMHO not bad to throttle requests in case of
error
Stress tests
- Test-machine: Intel Core i7 930 (4 x 2.8 GHz) (VMware
Req #52569 [Com]: Implement ondemand process-manager (to allow zero children)
Edit report at http://bugs.php.net/bug.php?id=52569edit=1
ID: 52569
Comment by: mplomer at gmx dot de
Reported by:mplomer at gmx dot de
Summary:Implement ondemand process-manager (to allow zero
children)
Status: Analyzed
Type: Feature/Change Request
Package:FPM related
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
Patch version 5:
- Added missing fpm_globals.is_child check (proposed by jerome)
- Implemented max children reached status counter.
- Fixed missing last_idle_child = NULL; in
fpm_pctl_perform_idle_server_maintenance which caused the routine to
shutdown only one (or a few?) processes per second globally instead per
pool, when you have multiple pools. I think this was not the intention,
and it's a bug.
Previous Comments:
[2010-08-27 08:38:34] f...@php.net
Updates to come:
1- there is a bug. after fork, child process seems to run code reverved
to the
parent process:
Aug 27 08:32:30.646905 [WARNING] pid 4335, fpm_stdio_child_said(), line
143:
[pool www_chroot] child 4450 said into stderr: Aug 27 08:32:30.628866
[DEBUG]
pid 4450, fpm_pctl_on_socket_accept(), line 529: [pool www_chroot] got
accept
without idle child available I forked, now=22184178.981102
2- the 1s max delay before resetting the fpm_pctl_on_socket_accept() is
in
theory enough. But I prefer to set a much smaller specific timer (~1ms)
just in
case. Imagine there is a bug and children becomes to segfault and it's
not
restarted. There will be a 1s delay (max) before it's forked again. I
now it's
the worst case scenario.
[2010-08-27 08:31:11] f...@php.net
here is a new revision:
1- I restore the backlog value check at startup. It's been simplified.
If it's
lower than 128, it's set to 128. I kept also the change of the backlog
default
value from -1 to 128. As the ondemand will certainely end up in trunk,
it's not
a violation of the 5.3 code.
2- you were right for the else if (wp-config-pm ==
PM_STYLE_ONDEMAND). I
thought there were a if (wp-config-pm == PM_STYLE_STATIC) on the
front of
the block
3- I change the libevent callback on pool listen_socket to prevent CPU
burns. If
max_childre is triggered, the callback function will be set up at next
process
maintenance call (every 1s).
[2010-08-27 08:27:20] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-ondemand.v4.patch
Revision: 1282890440
URL:
http://bugs.php.net/patch-display.php?bug=52569patch=fpm-ondemand.v4.patchrevision=1282890440
[2010-08-26 00:27:45] f...@php.net
For information, the listen.backlog default value has been changed from
-1 to
128 into trunk recentely: http://svn.php.net/viewvc?
view=revisionrevision=302725
This changed won't be applied to 5.3 branch so as the ondemand process
manager
as it's a (big ?) new feature. It could be discussed.
I like the listen_backlog adjustment. It was maybe not perfect but
setting it to
0 will make the on demand PM not working.
for the else if fix, you have to add an else {} in all the cases. If
there
is a bug somewhere else, it's not advised to have a case which could not
be
checked.
it looks great. Can you also provides test results ?
thx a LOT for you help and your time making PHP better.
[2010-08-26 00:15:47] mplomer at gmx dot de
I did some finetuning and cleanups in the fpm-ondemand-pm-v3.patch:
set listen_backlog default to 128 (to be discussed?)
removed listen_backlog adjustment (I considered that it is enough to
leave the default at 128, a greater value is mostly ignored by the
system anyway, and the number of requests in the backlog has rather
nothing to do with max_children. If you do not agree with this, feel
free to restore the old behaviour :-) )
renamed ondemand_process_timeout to process_idle_timeout (it's better, I
think)
fixed else if (wp-config-pm == PM_STYLE_ONDEMAND) in fpm_conf.c (was
only else before)
removed config-pm_(start/min_spare/max_spare)_servers = 0; ... in
fpm_conf.c (should not be used anyway when pm = ondemand)
log libevent version in fpm_event_init_main
updated some comments in sample config
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/bug.php?id=52569
--
Edit this bug report at http://bugs.php.net/bug.php?id=52569edit=1
Req #52569 [Com]: Implement ondemand process-manager (to allow zero children)
Edit report at http://bugs.php.net/bug.php?id=52569edit=1 ID: 52569 Comment by: mplomer at gmx dot de Reported by:mplomer at gmx dot de Summary:Implement ondemand process-manager (to allow zero children) Status: Analyzed Type: Feature/Change Request Package:FPM related PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: Some test results of the ondemand-pm: General - Pool has to start with 0 children - OK - Handling and checking of new config options - OK Concurrent requests - Children has to be forked immediately on new requests without delay - OK - Idle children has to be killed after pm.process_idle_timeout + 0-1s - OK - When there are more than one idle children, kill only one per second PER POOL - OK Reaching pm.max_children limit - No more processes has to be created - OK - Requests have to wait until one child becomes idle and then get handled immediately without further delay - OK - When limit is reached, issue a warning and increase status counter (and do this only once) - OK: Aug 28 13:39:41.537174 [WARNING] pid 27540, fpm_pctl_on_socket_accept(), line 507: [pool www] server reached max_children setting (10), consider raising it - Warning is re-issued after children count decreases and hit the limit again - OK CPU burns - When reaching max_children limit, pause libevent callback and reenable it in the maintenance routine, to avoid CPU burns - OK - When children takes too long to accept() the request, avoid CPU burn - NOTOK - happens sometimes (in praxis only sometimes after forking) - to reproduce add an usleep(5) in children's code after fork(), or apachebench with ~200 concurrent requests :-) - You get a lot of: fpm_pctl_on_socket_accept(), line 502: [pool www] fpm_pctl_on_socket_accept() called - It's not a big problem, because this doesn't take much time (in one rare case it took ~90ms on my machine), but it's not nice, especially when the server is flooded with requests - one idea: - do not re-enable event-callback in fpm_pctl_on_socket_accept - send an event from children just after accept() to parent process - re-enable event-callback in parent process, when it receives this event from children - in case of an error it is re-enabled in the maintainance routine after max 1s, which is IMHO not bad to throttle requests in case of error Stress tests - Test-machine: Intel Core i7 930 (4 x 2.8 GHz) (VMware with 256 MB RAM) - Testing with 100 concurrent requests on the same pool to a sleep(10); php script with 0 running processes and max_children = 200: - took about 4ms per fork in average - 25 processes are forked in one block (timeslice?), after this there is a gap of 200-1000ms - took about 125ms to fork 25 children - took about 2.5s to fork all 100 children and accept the requests - Testing with 200 concurrent requests - hits RAM limit of VM, so it's maybe not meaningful - took ~10.5s to fork all 200 children and accept the requests - Testing with 10 concurrent requests on 20 pools (so in fact 200 concurrent requests) - took ~11.2s to fork all 200 children and accept the requests - all children are killed after process_timeout + 10s (1 process per second per pool is killed) - OK Previous Comments: [2010-08-30 10:18:14] mplomer at gmx dot de Patch version 5: - Added missing fpm_globals.is_child check (proposed by jerome) - Implemented max children reached status counter. - Fixed missing last_idle_child = NULL; in fpm_pctl_perform_idle_server_maintenance which caused the routine to shutdown only one (or a few?) processes per second globally instead per pool, when you have multiple pools. I think this was not the intention, and it's a bug. [2010-08-27 08:38:34] f...@php.net Updates to come: 1- there is a bug. after fork, child process seems to run code reverved to the parent process: Aug 27 08:32:30.646905 [WARNING] pid 4335, fpm_stdio_child_said(), line 143: [pool www_chroot] child 4450 said into stderr: Aug 27 08:32:30.628866 [DEBUG] pid 4450, fpm_pctl_on_socket_accept(), line 529: [pool www_chroot] got accept without idle child available I forked, now=22184178.981102 2- the 1s max delay before resetting the fpm_pctl_on_socket_accept() is in theory enough. But I prefer to set a much smaller specific timer (~1ms) just in case. Imagine there is a bug and children becomes to segfault and it's not restarted. There will be a 1s delay (max) before it's forked again. I now it's the worst case scenario. [2010-08-27 08:31:11] f...@php.net here is a new revision: 1- I restore the backlog value check at startup
[PHP-BUG] Req #52569 [NEW]: Allow zero pm.start_servers/pm.min_spare_servers
From: Operating system: PHP version: 5.3.3 Package: FPM related Bug Type: Feature/Change Request Bug description:Allow zero pm.start_servers/pm.min_spare_servers Description: We are currently implementing PHP-FPM in a shared hosting environment. We have many users on one server (about 200) and we have to define one pool for each customer (each with a different uid). If PHP-FPM starts one children per customer at startup, this would kill the servers, I think. So we have to start them on demand. When using PHP via mod_fcgid/suEXEC you can define FcgidMinProcessesPerClass 0, which works fine, but in PHP-FPM this is not allowed. I tried to remove the check in fpm_conf.c: if (config-pm_min_spare_servers = 0) if (config-pm_start_servers = 0) but this does not really work (zero children are created at startup which is fine, but no child is created on request and the request hangs). I currently don't find the right entry point. -- Edit bug report at http://bugs.php.net/bug.php?id=52569edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52569r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52569r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52569r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52569r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52569r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52569r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52569r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52569r=needscript Try newer version: http://bugs.php.net/fix.php?id=52569r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52569r=support Expected behavior: http://bugs.php.net/fix.php?id=52569r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52569r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52569r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52569r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52569r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52569r=dst IIS Stability: http://bugs.php.net/fix.php?id=52569r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52569r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52569r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52569r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52569r=mysqlcfg
#34945 [Com]: exec(): Problem with quotes in commandline
ID: 34945
Comment by: mplomer at gmx dot de
Reported By: mplomer at gmx dot de
Status: Open
Bug Type: Feature/Change Request
Operating System: WinXP
PHP Version: 5CVS-2005-10-21 (snap)
New Comment:
Since PHP 5.2.1 the proc_open() function has a new parameter
bypass_shell, which is the needed feature.
It would be nice to have the same solution for all other shell related
functions (exec,shell_exec,system,...). For example via a php.ini
option.
Previous Comments:
[2005-10-27 19:38:14] mplomer at gmx dot de
cmd.exe /C accepts only two quotes in a commandline. If there are more,
then the first and the last quote is removed.
This makes it impossible to pass commandlines like:
C:/Program Files/bla/bla.exe c:/my files/bla.txt
So it is IMHO the best way, if we create an option to bypass the
command-interpreter.
[2005-10-21 14:58:25] cspeer at gmx dot de
I have the same problem. I have also no solution to execute commands
with many quotes.
[2005-10-21 14:18:37] mplomer at gmx dot de
Sure, it's not directly a Bug in PHP, but it's a feature-request to
workaround a bug/feature of cmd.exe:
We need a possibility to bypass the command-interpreter for execution
of commands, since cmd.exe can't execute it complete correctly.
Or someone finds a solution to escape quotes correctly. I will check
this out over the weekend ;-)
[2005-10-21 12:58:36] tony2...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
[2005-10-21 12:54:39] mplomer at gmx dot de
Description:
If i have a complicated commandline with quotes and spaces in it, and
pass it to exec(), system(), ..., then i get under Windows path or
filename not found despite the filenames are correct.
The Problem is the following:
PHP starts a command over the command-interpreter by prefixing the
commandline with cmd.exe /c .
Test in DOS-Box:
If I enter the command in a DOS-Box, the result is ok, but if I
prefix it with cmd.exe /c , then i get the same failure as in PHP.
If you read the manpage (cmd.exe /?), there is a hint, that
cmd.exe /c has problems with quotes. And IMHO there is no way to
escape theese quotes.
My solutions are:
- Someone finds a way to escape quotes for cmd.exe
- A new Parameter for system()/exec()/...
- ... or better: A php.ini-setting, ... which controls, if the command
is executed over the shell, or executed directly.
Reproduce code:
---
system('D:\Program Files\fop\fop.bat path with blanks/to/bla.fo
output path/bla.pdf');
Expected result:
Successful execution.
Actual result:
--
cmd.exe says: path/file not found
--
Edit this bug report at http://bugs.php.net/?id=34945edit=1
#44164 [NEW]: Clear Content-Length HTTP header when zlib.output_compression active
From: mplomer at gmx dot de
Operating system: any
PHP version: 5.2.5
PHP Bug Type: Zlib Related
Bug description: Clear Content-Length HTTP header when
zlib.output_compression active
Description:
If you have a big project, where Content-Length header is set on many
places, and then you turn on zlib.output_compression, you will have a
problem, because the original header is still passed through, but it is
invalid now, because it contains the length of the uncompressed data
instead of the compressed data.
This would confuse some HTTP clients, that rely on the Content-Length.
I think, zlib.output_compression should be completely transparent, so
this issue should be handled in php core.
One solution is, to remove the Content-Length header (if set) in
ob_gzhandler() in ext/zlib/zlib.c:882 (where Content-Encoding: gzip
header is set). If you see a good way to set the Content-Length to the
compressed length, this would be, of course, the best solution, but this is
IMHO only possible, if the entire data is buffered before (or is this done
by ob_gzhandler anyway?).
This would make the various workarounds irrelevant that have to be done if
zlib.output_compression is active and is completely backward compatible.
Reproduce code:
---
In php.ini:
zlib.output_compression = On
?php
$output = str_repeat('A', 8192);
header('Content-Length: ' . strlen($output));
?
Expected result:
Correct Content-Length header or removed Content-Length header in
response, because the old length is always wrong. Better send no
Content-Length instead a wrong length.
Actual result:
--
The old Content-Length header is sent.
--
Edit bug report at http://bugs.php.net/?id=44164edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44164r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44164r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44164r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44164r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44164r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44164r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44164r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44164r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44164r=support
Expected behavior:http://bugs.php.net/fix.php?id=44164r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44164r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44164r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44164r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44164r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44164r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44164r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44164r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44164r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44164r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44164r=mysqlcfg
#44164 [Opn]: Handle Content-Length HTTP header when zlib.output_compression active
ID: 44164
User updated by: mplomer at gmx dot de
-Summary: Clear Content-Length HTTP header when
zlib.output_compression active
Reported By: mplomer at gmx dot de
Status: Open
Bug Type: Zlib Related
Operating System: any
PHP Version: 5.2.5
New Comment:
Another idea is:
IF the Content-Length header IS set from the script,
THEN buffer the complete output and calculate the correct compressed
Content-Length.
ELSE do nothing (do not add any Content-Length header)
So ob_flush(), flush() will still work if compression is active. (Which
will not work, if we use apache's mod_deflate. This is why
zlib.output_compression is required.)
Previous Comments:
[2008-02-19 10:48:09] mplomer at gmx dot de
Description:
If you have a big project, where Content-Length header is set on many
places, and then you turn on zlib.output_compression, you will have a
problem, because the original header is still passed through, but it is
invalid now, because it contains the length of the uncompressed data
instead of the compressed data.
This would confuse some HTTP clients, that rely on the
Content-Length.
I think, zlib.output_compression should be completely transparent, so
this issue should be handled in php core.
One solution is, to remove the Content-Length header (if set) in
ob_gzhandler() in ext/zlib/zlib.c:882 (where Content-Encoding: gzip
header is set). If you see a good way to set the Content-Length to the
compressed length, this would be, of course, the best solution, but this
is IMHO only possible, if the entire data is buffered before (or is this
done by ob_gzhandler anyway?).
This would make the various workarounds irrelevant that have to be done
if zlib.output_compression is active and is completely backward
compatible.
Reproduce code:
---
In php.ini:
zlib.output_compression = On
?php
$output = str_repeat('A', 8192);
header('Content-Length: ' . strlen($output));
?
Expected result:
Correct Content-Length header or removed Content-Length header in
response, because the old length is always wrong. Better send no
Content-Length instead a wrong length.
Actual result:
--
The old Content-Length header is sent.
--
Edit this bug report at http://bugs.php.net/?id=44164edit=1
#41713 [Asn]: Persistent memory consumption since 5.2
ID: 41713 User updated by: mplomer at gmx dot de Reported By: mplomer at gmx dot de Status: Assigned Bug Type: Performance problem Operating System: win32 only PHP Version: 5.2CVS-2007-07-12 Assigned To: dmitry New Comment: Yes, seems this is the same problem. You could try to reproduce this with the 4-line test script from the comment from [30 Jun 10:19am UTC] and the Reproduce procedure from the initial bug report on your machine. But Jani could already reproduce the bug and it is now assigned to Dmitry, so we will wait for his comments ;-) Previous Comments: [2007-07-16 23:23:32] stephen dot johnston at guildlaunch dot com We are seeing a similar problem in 5.2.3 with Apache 2.0.59 and 4g of RAM. After a few hours of running with more than 70 threads per child in Apache PHP will start throwing errors saying out of memory with seemingly random memory sizes. It seems to happen in our environment once Apache's memory usage reaches around 1gig, but that is not always the case. Our site is growing fast and we need to be able to up Apache threads without recycling Apache every 2 hours. Unfortunately, the PHP community in general seems to respond to error reports relating to this with increase your memory limit. This is *not* a memory limit issue. I would be more than willing to work with you all to provide debug info, but we cannot reproduce this in our test environement with load testing and I don't want to mess around with our production environment without some specific direction on how to correctly profile this issue. [2007-07-14 21:15:15] [EMAIL PROTECTED] And I can reproduce this too on Windows, using latest snapshot available. [2007-07-14 09:15:28] [EMAIL PROTECTED] Dmitry, please check this out. [2007-07-11 08:43:55] mplomer at gmx dot de I tested with PHP 5.2.0 now, and I can reproduce the described behaviour from [30 Jun 10:19am UTC] too. Only when I am testing with PHP 5.1.6, I can't reproduce it. But I agree with you, that this points at the new memory management on win32. [2007-07-10 23:39:09] spamtrap at psychoticwolf dot net I see this with PHP 5.2.1 - 5.2.3 (mod_php5 with Apache 2.0.59 and 2.2.4 on WinXP and Win2003). I did some regression testing and it seems to have started between 5.2.0 and 5.2.1 which points at the new memory management on win32. Memload was normal under 5.2.0. After awhile, Apache consumes as previously reported, 300-600mb (usually around 330mb + 6-700mb virtual), and, curiously, PHP thows a Fatal Error that its exceeded its memory limit for that script, even though it hasn't, as the script doesn't use more than about 300k. (Only seen this last part once, so far, so that might be a fluke.) 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/41713 -- Edit this bug report at http://bugs.php.net/?id=41713edit=1
#41713 [Opn]: Persistent memory consumption since 5.2
ID: 41713
User updated by: mplomer at gmx dot de
Reported By: mplomer at gmx dot de
Status: Open
Bug Type: Performance problem
Operating System: win32 only
PHP Version: 5.2.4-dev 2007-06-26 00:09
New Comment:
I tested with PHP 5.2.0 now, and I can reproduce the described
behaviour from [30 Jun 10:19am UTC] too. Only when I am testing with PHP
5.1.6, I can't reproduce it.
But I agree with you, that this points at the new memory management on
win32.
Previous Comments:
[2007-07-10 23:39:09] spamtrap at psychoticwolf dot net
I see this with PHP 5.2.1 - 5.2.3 (mod_php5 with Apache 2.0.59 and
2.2.4 on WinXP and Win2003). I did some regression testing and it seems
to have started between 5.2.0 and 5.2.1 which points at the new memory
management on win32. Memload was normal under 5.2.0. After awhile,
Apache consumes as previously reported, 300-600mb (usually around 330mb
+ 6-700mb virtual), and, curiously, PHP thows a Fatal Error that its
exceeded its memory limit for that script, even though it hasn't, as the
script doesn't use more than about 300k. (Only seen this last part once,
so far, so that might be a fluke.)
[2007-07-09 13:48:22] mplomer at gmx dot de
Does somebody have any ideas to track this down?
Are there any PHP core developers with a windows-test-environment?
Aren't there any PHP developers who have the problem, that Apache/PHP
eats up all RAM after some hours of developing and testing bigger
PHP-projects?
[2007-06-30 11:32:59] mplomer at gmx dot de
Another developer tested this on his own machine now, with the same
Apache/PHP environment, and could affirm this behavior. The memory usage
values are respectively 0,1-0,3 MB different, but the principle is the
same. So the behavior seems not to be system dependent.
[2007-06-30 10:19:26] mplomer at gmx dot de
OK, it took me some time to get FastCGI running, but now it works,
and yes ... I can reproduce it there, too.
To be more detailed, I set up the following environment:
- Apache 2.0.59 (minimalistic configuration) with
mod_fastcgi-SNAP-0404142202-AP2.dll
- Configured FastCGI with 1 process:
FastCgiServer ../php5/php-cgi.exe -processes 1
- PHP 5.2.3 (without php.ini; only php-cgi.exe and php5ts.dll)
- and the test-script with 400,000 array elements:
?php
$elementCount = 40;
for ($i = 0; $i $elementCount; $i++) {
$variables[$i] = 'x';
}
?
Reproducing by looking at the Task-Manager's memory usage
values after each execution of the script:
- Freshly starting Apache
- Child process php-cgi.exe is started
[php-cgi.exe consumes ~ 4.1 MB]
- Execute the test-script the first time:
[php-cgi.exe consumes ~ 4.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 4.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 5.3 MB]
... might be OK so long
- Execute one more time: [php-cgi.exe consumes ~ 36.4 MB !!!]
... from now on this is not OK anymore
- Execute one more time: [php-cgi.exe consumes ~ 36.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 6.1 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.4 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.5 MB]
- Execute one more time: [php-cgi.exe consumes ~ 7.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 5.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.4 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.5 MB]
- Execute one more time: [php-cgi.exe consumes ~ 10.6 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 5.5 MB]
- ...
This is always reproducable, and the memory usage values
are quite the same on each reproducion. (They differ only
sometimes in 4-12 KB.)
But you see, there is a systematic. There are 2 executions,
after which the memory is not freed, and after the third
execution, the memory is mostly freed.
Any ideas for further testing?
[2007-06-28 00:41:49] [EMAIL PROTECTED]
Thank you, at least we know it only happens with Windows.
Have you tried running PHP as FastCGI under windows?
That might cure this too..
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/41713
--
Edit this bug report at http://bugs.php.net/?id=41713edit=1
#41713 [Opn]: Persistent memory consumption since 5.2
ID: 41713
User updated by: mplomer at gmx dot de
Reported By: mplomer at gmx dot de
Status: Open
Bug Type: Performance problem
Operating System: win32 only
PHP Version: 5.2.4-dev 2007-06-26 00:09
New Comment:
Does somebody have any ideas to track this down?
Are there any PHP core developers with a windows-test-environment?
Aren't there any PHP developers who have the problem, that Apache/PHP
eats up all RAM after some hours of developing and testing bigger
PHP-projects?
Previous Comments:
[2007-06-30 11:32:59] mplomer at gmx dot de
Another developer tested this on his own machine now, with the same
Apache/PHP environment, and could affirm this behavior. The memory usage
values are respectively 0,1-0,3 MB different, but the principle is the
same. So the behavior seems not to be system dependent.
[2007-06-30 10:19:26] mplomer at gmx dot de
OK, it took me some time to get FastCGI running, but now it works,
and yes ... I can reproduce it there, too.
To be more detailed, I set up the following environment:
- Apache 2.0.59 (minimalistic configuration) with
mod_fastcgi-SNAP-0404142202-AP2.dll
- Configured FastCGI with 1 process:
FastCgiServer ../php5/php-cgi.exe -processes 1
- PHP 5.2.3 (without php.ini; only php-cgi.exe and php5ts.dll)
- and the test-script with 400,000 array elements:
?php
$elementCount = 40;
for ($i = 0; $i $elementCount; $i++) {
$variables[$i] = 'x';
}
?
Reproducing by looking at the Task-Manager's memory usage
values after each execution of the script:
- Freshly starting Apache
- Child process php-cgi.exe is started
[php-cgi.exe consumes ~ 4.1 MB]
- Execute the test-script the first time:
[php-cgi.exe consumes ~ 4.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 4.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 5.3 MB]
... might be OK so long
- Execute one more time: [php-cgi.exe consumes ~ 36.4 MB !!!]
... from now on this is not OK anymore
- Execute one more time: [php-cgi.exe consumes ~ 36.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 6.1 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.4 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.5 MB]
- Execute one more time: [php-cgi.exe consumes ~ 7.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 5.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.4 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.5 MB]
- Execute one more time: [php-cgi.exe consumes ~ 10.6 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 5.5 MB]
- ...
This is always reproducable, and the memory usage values
are quite the same on each reproducion. (They differ only
sometimes in 4-12 KB.)
But you see, there is a systematic. There are 2 executions,
after which the memory is not freed, and after the third
execution, the memory is mostly freed.
Any ideas for further testing?
[2007-06-28 00:41:49] [EMAIL PROTECTED]
Thank you, at least we know it only happens with Windows.
Have you tried running PHP as FastCGI under windows?
That might cure this too..
[2007-06-27 20:56:14] mplomer at gmx dot de
OK, no problem. ... Today I tested this with apache worker, but I still
cannot reproduce it under linux.
I used a Debian 4.0 system and I compiled Apache 2.2.4 with:
./configure --prefix=/usr/local/apache2 --with-included-apr
--with-mpm=worker --enable-so
... and PHP 5.2.3 with:
./configure --prefix=/usr/local/php
--with-apxs2=/usr/local/apache2/bin/apxs --enable-memory-limit
So phpinfo() said, Thread Safety is enabled. And I played around with
the elementCount ... but under linux the memory is always completely
freed.
If you have some tips to track this down inside PHP, please let me
know. I now have a working PHP build-environment under windows.
[2007-06-27 11:54:27] [EMAIL PROTECTED]
It's most likely a ZTS issue, so testing on *nix with e.g. apache
worker and apache2handler SAPI might be a good idea too..
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/41713
--
Edit this bug report at http://bugs.php.net/?id=41713edit=1
#41713 [Fbk-Opn]: Persistent memory consumption since 5.2
ID: 41713
User updated by: mplomer at gmx dot de
Reported By: mplomer at gmx dot de
-Status: Feedback
+Status: Open
Bug Type: Performance problem
Operating System: win32 only
PHP Version: 5.2.4-dev 2007-06-26 00:09
New Comment:
OK, it took me some time to get FastCGI running, but now it works,
and yes ... I can reproduce it there, too.
To be more detailed, I set up the following environment:
- Apache 2.0.59 (minimalistic configuration) with
mod_fastcgi-SNAP-0404142202-AP2.dll
- Configured FastCGI with 1 process:
FastCgiServer ../php5/php-cgi.exe -processes 1
- PHP 5.2.3 (without php.ini; only php-cgi.exe and php5ts.dll)
- and the test-script with 400,000 array elements:
?php
$elementCount = 40;
for ($i = 0; $i $elementCount; $i++) {
$variables[$i] = 'x';
}
?
Reproducing by looking at the Task-Manager's memory usage
values after each execution of the script:
- Freshly starting Apache
- Child process php-cgi.exe is started
[php-cgi.exe consumes ~ 4.1 MB]
- Execute the test-script the first time:
[php-cgi.exe consumes ~ 4.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 4.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 5.3 MB]
... might be OK so long
- Execute one more time: [php-cgi.exe consumes ~ 36.4 MB !!!]
... from now on this is not OK anymore
- Execute one more time: [php-cgi.exe consumes ~ 36.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 6.1 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.4 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.5 MB]
- Execute one more time: [php-cgi.exe consumes ~ 7.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 5.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.4 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.5 MB]
- Execute one more time: [php-cgi.exe consumes ~ 10.6 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 5.5 MB]
- ...
This is always reproducable, and the memory usage values
are quite the same on each reproducion. (They differ only
sometimes in 4-12 KB.)
But you see, there is a systematic. There are 2 executions,
after which the memory is not freed, and after the third
execution, the memory is mostly freed.
Any ideas for further testing?
Previous Comments:
[2007-06-28 00:41:49] [EMAIL PROTECTED]
Thank you, at least we know it only happens with Windows.
Have you tried running PHP as FastCGI under windows?
That might cure this too..
[2007-06-27 20:56:14] mplomer at gmx dot de
OK, no problem. ... Today I tested this with apache worker, but I still
cannot reproduce it under linux.
I used a Debian 4.0 system and I compiled Apache 2.2.4 with:
./configure --prefix=/usr/local/apache2 --with-included-apr
--with-mpm=worker --enable-so
... and PHP 5.2.3 with:
./configure --prefix=/usr/local/php
--with-apxs2=/usr/local/apache2/bin/apxs --enable-memory-limit
So phpinfo() said, Thread Safety is enabled. And I played around with
the elementCount ... but under linux the memory is always completely
freed.
If you have some tips to track this down inside PHP, please let me
know. I now have a working PHP build-environment under windows.
[2007-06-27 11:54:27] [EMAIL PROTECTED]
It's most likely a ZTS issue, so testing on *nix with e.g. apache
worker and apache2handler SAPI might be a good idea too..
[2007-06-27 11:42:32] [EMAIL PROTECTED]
Too bad we don't have any developers maintaining Windows port on a
daily basis.
So you're encouraged to help us and investigate the issue.
Any additional information you can find would be appreciated.
[2007-06-26 11:37:27] mplomer at gmx dot de
It seems so. I could reproduce it only under windows yet. (See my
comment from [17 Jun 9:04am UTC]).
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/41713
--
Edit this bug report at http://bugs.php.net/?id=41713edit=1
#41713 [Opn]: Persistent memory consumption since 5.2
ID: 41713
User updated by: mplomer at gmx dot de
Reported By: mplomer at gmx dot de
Status: Open
Bug Type: Performance problem
Operating System: win32 only
PHP Version: 5.2.4-dev 2007-06-26 00:09
New Comment:
Another developer tested this on his own machine now, with the same
Apache/PHP environment, and could affirm this behavior. The memory usage
values are respectively 0,1-0,3 MB different, but the principle is the
same. So the behavior seems not to be system dependent.
Previous Comments:
[2007-06-30 10:19:26] mplomer at gmx dot de
OK, it took me some time to get FastCGI running, but now it works,
and yes ... I can reproduce it there, too.
To be more detailed, I set up the following environment:
- Apache 2.0.59 (minimalistic configuration) with
mod_fastcgi-SNAP-0404142202-AP2.dll
- Configured FastCGI with 1 process:
FastCgiServer ../php5/php-cgi.exe -processes 1
- PHP 5.2.3 (without php.ini; only php-cgi.exe and php5ts.dll)
- and the test-script with 400,000 array elements:
?php
$elementCount = 40;
for ($i = 0; $i $elementCount; $i++) {
$variables[$i] = 'x';
}
?
Reproducing by looking at the Task-Manager's memory usage
values after each execution of the script:
- Freshly starting Apache
- Child process php-cgi.exe is started
[php-cgi.exe consumes ~ 4.1 MB]
- Execute the test-script the first time:
[php-cgi.exe consumes ~ 4.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 4.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 5.3 MB]
... might be OK so long
- Execute one more time: [php-cgi.exe consumes ~ 36.4 MB !!!]
... from now on this is not OK anymore
- Execute one more time: [php-cgi.exe consumes ~ 36.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 6.1 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.4 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.5 MB]
- Execute one more time: [php-cgi.exe consumes ~ 7.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 5.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.4 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.5 MB]
- Execute one more time: [php-cgi.exe consumes ~ 10.6 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.7 MB]
- Execute one more time: [php-cgi.exe consumes ~ 36.8 MB]
- Execute one more time: [php-cgi.exe consumes ~ 5.5 MB]
- ...
This is always reproducable, and the memory usage values
are quite the same on each reproducion. (They differ only
sometimes in 4-12 KB.)
But you see, there is a systematic. There are 2 executions,
after which the memory is not freed, and after the third
execution, the memory is mostly freed.
Any ideas for further testing?
[2007-06-28 00:41:49] [EMAIL PROTECTED]
Thank you, at least we know it only happens with Windows.
Have you tried running PHP as FastCGI under windows?
That might cure this too..
[2007-06-27 20:56:14] mplomer at gmx dot de
OK, no problem. ... Today I tested this with apache worker, but I still
cannot reproduce it under linux.
I used a Debian 4.0 system and I compiled Apache 2.2.4 with:
./configure --prefix=/usr/local/apache2 --with-included-apr
--with-mpm=worker --enable-so
... and PHP 5.2.3 with:
./configure --prefix=/usr/local/php
--with-apxs2=/usr/local/apache2/bin/apxs --enable-memory-limit
So phpinfo() said, Thread Safety is enabled. And I played around with
the elementCount ... but under linux the memory is always completely
freed.
If you have some tips to track this down inside PHP, please let me
know. I now have a working PHP build-environment under windows.
[2007-06-27 11:54:27] [EMAIL PROTECTED]
It's most likely a ZTS issue, so testing on *nix with e.g. apache
worker and apache2handler SAPI might be a good idea too..
[2007-06-27 11:42:32] [EMAIL PROTECTED]
Too bad we don't have any developers maintaining Windows port on a
daily basis.
So you're encouraged to help us and investigate the issue.
Any additional information you can find would be appreciated.
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/41713
--
Edit this bug report at http://bugs.php.net/?id=41713edit=1
#41713 [Opn]: Persistent memory consumption since 5.2
ID: 41713 User updated by: mplomer at gmx dot de Reported By: mplomer at gmx dot de Status: Open Bug Type: Performance problem Operating System: Windows PHP Version: 5.2.4-dev 2007-06-26 00:09 New Comment: OK, no problem. ... Today I tested this with apache worker, but I still cannot reproduce it under linux. I used a Debian 4.0 system and I compiled Apache 2.2.4 with: ./configure --prefix=/usr/local/apache2 --with-included-apr --with-mpm=worker --enable-so ... and PHP 5.2.3 with: ./configure --prefix=/usr/local/php --with-apxs2=/usr/local/apache2/bin/apxs --enable-memory-limit So phpinfo() said, Thread Safety is enabled. And I played around with the elementCount ... but under linux the memory is always completely freed. If you have some tips to track this down inside PHP, please let me know. I now have a working PHP build-environment under windows. Previous Comments: [2007-06-27 11:54:27] [EMAIL PROTECTED] It's most likely a ZTS issue, so testing on *nix with e.g. apache worker and apache2handler SAPI might be a good idea too.. [2007-06-27 11:42:32] [EMAIL PROTECTED] Too bad we don't have any developers maintaining Windows port on a daily basis. So you're encouraged to help us and investigate the issue. Any additional information you can find would be appreciated. [2007-06-26 11:37:27] mplomer at gmx dot de It seems so. I could reproduce it only under windows yet. (See my comment from [17 Jun 9:04am UTC]). [2007-06-26 11:10:41] [EMAIL PROTECTED] Is this windows only issue? [2007-06-26 06:52:27] mplomer at gmx dot de I can still reproduce this. I tested this with the actual 5.2.4-dev 2007-06-26 00:09 snapshot without php.ini. Today with 20 array elements I needed 6 or 7 script executions, with 40 elements I need 2-3 script executions, and with 80 I could not reproduce the problem. Could you reproduce the problem? Or do you need some additional infos to reproduce it? PS: Now httpd.exe crashes on every shutdown, but this possibly another bug ;-) 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/41713 -- Edit this bug report at http://bugs.php.net/?id=41713edit=1
#41713 [Fbk-Opn]: Persistent memory consumption since 5.2
ID: 41713 User updated by: mplomer at gmx dot de Reported By: mplomer at gmx dot de -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Windows -PHP Version: 5.2.3 +PHP Version: 5.2.4-dev 2007-06-26 00:09 New Comment: I can still reproduce this. I tested this with the actual 5.2.4-dev 2007-06-26 00:09 snapshot without php.ini. Today with 20 array elements I needed 6 or 7 script executions, with 40 elements I need 2-3 script executions, and with 80 I could not reproduce the problem. Could you reproduce the problem? Or do you need some additional infos to reproduce it? PS: Now httpd.exe crashes on every shutdown, but this possibly another bug ;-) Previous Comments: [2007-06-25 18:08:09] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-06-19 06:25:38] mplomer at gmx dot de By the way ... I disabled all PHP extensions, and used the standard php.ini settings. [2007-06-17 09:04:01] mplomer at gmx dot de I tested this under Linux today, and I could not reproduce it here. Apache's memory consumption is ~10MB after each request, regardless of the elementCount of the test-array. It seems to be a Windows specific problem. I compiled PHP under Linux without and with Thread-Safety (--enable-maintainer-zts) enabled (because under Windows this is activated), but it seems this has no influence. [2007-06-16 16:48:04] mplomer at gmx dot de Description: When using php arrays with a lot of entries (about 20), I figured out the following problem: PHP sometimes doesn't free all used memory after completing the request. Apache uses under some circumstances 20-30 MB more RAM after the request. The problem is that this happens per child. If an Apache runs with 64 threads, it is possible, that httpd.exe consumes persistently 300-600 MB of RAM, even without any active request. Reproduce environment: - I tested it under an Apache (1.3 and 2.2) environment unter Windows (XP) (I didn't test it under Linux yet) - Used PHP-Version: 5.2.3 - the problem was introduced with PHP 5.2. With PHP 5.1.6 the problem does not appear (but I noticed, that PHP 5.1.6's memory management is much slower than the new one :-) - Set ThreadsPerChild to 1 in httpd.conf to make sure, you hit always the same PHP instance and avoid any constraints Reproduce procedure: - Freshly start your 1-thread-Apache [It will consume about 10 MB] - Execute the following script [Memory usage will grow to ~50-60 MB, and after execution memory usage shrinks back to ~10 MB again ... works fine so long] - Execute the script again 2 or more times [... and surprisingly Apache consumes about 35MB after the request is complete!] (The number of executions you need to reproduce the problem depends on the elementCount of the test-array, and eventually some system dependent factors; see reproduce code) - If you excecute the script some more times again, someimes the memory is freed and memory usage is about 10MB again, but after some further requests, the memory is NOT freed again. Because of the last point, I think, it is not a memory leak. I also compiled PHP as debug version and there where no memory leaks reported (with report_memleaks = On). But I still think, the consumed memory should be completely freed after _each_ request. If this is a feature, because something is cached, it requires a maximum of the cache size. 20-30MB per child is definitely too much. If you put an echo memory_get_peak_usage(true); at the beginning of the script, you will see, that PHP claims to use only about 200-300 KB at every script start time. It doesn't report the 20-30MB that it consumes since the last execution. I tested this with an array, but the problem can, of course, be deeper in the new memory management of PHP 5.2 Reproduce code: --- ?php // elementCount: Count of elements which are created in the test array: // - a count of 20 demonstrates the problem at best on my machine // - a count of 10 or lesser reproduces the problem too, but you need more // calls of the script (browser refreshes) until the problem occurs // - with a count of 40 or more I couldn't reproduce the problem, // there it works fine // I couldn't figure out exactly, on which factors this count depends on, but // it _seems_ to be not machine dependent, but play around with it. // Note also, that the count of array elements
#41713 [Fbk-Opn]: Persistent memory consumption since 5.2
ID: 41713 User updated by: mplomer at gmx dot de Reported By: mplomer at gmx dot de -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 5.2.4-dev 2007-06-26 00:09 New Comment: It seems so. I could reproduce it only under windows yet. (See my comment from [17 Jun 9:04am UTC]). Previous Comments: [2007-06-26 11:10:41] [EMAIL PROTECTED] Is this windows only issue? [2007-06-26 06:52:27] mplomer at gmx dot de I can still reproduce this. I tested this with the actual 5.2.4-dev 2007-06-26 00:09 snapshot without php.ini. Today with 20 array elements I needed 6 or 7 script executions, with 40 elements I need 2-3 script executions, and with 80 I could not reproduce the problem. Could you reproduce the problem? Or do you need some additional infos to reproduce it? PS: Now httpd.exe crashes on every shutdown, but this possibly another bug ;-) [2007-06-25 18:08:09] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-06-19 06:25:38] mplomer at gmx dot de By the way ... I disabled all PHP extensions, and used the standard php.ini settings. [2007-06-17 09:04:01] mplomer at gmx dot de I tested this under Linux today, and I could not reproduce it here. Apache's memory consumption is ~10MB after each request, regardless of the elementCount of the test-array. It seems to be a Windows specific problem. I compiled PHP under Linux without and with Thread-Safety (--enable-maintainer-zts) enabled (because under Windows this is activated), but it seems this has no influence. 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/41713 -- Edit this bug report at http://bugs.php.net/?id=41713edit=1
#41713 [Opn]: Persistent memory consumption since 5.2
ID: 41713
User updated by: mplomer at gmx dot de
-Summary: Persistent memory consumption
Reported By: mplomer at gmx dot de
Status: Open
Bug Type: *General Issues
Operating System: Windows
PHP Version: 5.2.3
New Comment:
By the way ... I disabled all PHP extensions, and used the standard
php.ini settings.
Previous Comments:
[2007-06-17 09:04:01] mplomer at gmx dot de
I tested this under Linux today, and I could not reproduce it here.
Apache's memory consumption is ~10MB after each request, regardless of
the elementCount of the test-array. It seems to be a Windows specific
problem.
I compiled PHP under Linux without and with Thread-Safety
(--enable-maintainer-zts) enabled (because under Windows this is
activated), but it seems this has no influence.
[2007-06-16 16:48:04] mplomer at gmx dot de
Description:
When using php arrays with a lot of entries (about 20), I figured
out the following problem: PHP sometimes doesn't free all used memory
after completing the request. Apache uses under some circumstances 20-30
MB more RAM after the request. The problem is that this happens per
child. If an Apache runs with 64 threads, it is possible, that httpd.exe
consumes persistently 300-600 MB of RAM, even without any active
request.
Reproduce environment:
- I tested it under an Apache (1.3 and 2.2) environment unter Windows
(XP) (I didn't test it under Linux yet)
- Used PHP-Version: 5.2.3 - the problem was introduced with PHP 5.2.
With PHP 5.1.6 the problem does not appear (but I noticed, that PHP
5.1.6's memory management is much slower than the new one :-)
- Set ThreadsPerChild to 1 in httpd.conf to make sure, you hit always
the same PHP instance and avoid any constraints
Reproduce procedure:
- Freshly start your 1-thread-Apache [It will consume about 10 MB]
- Execute the following script [Memory usage will grow to ~50-60 MB,
and after execution memory usage shrinks back to ~10 MB again ... works
fine so long]
- Execute the script again 2 or more times [... and surprisingly Apache
consumes about 35MB after the request is complete!] (The number of
executions you need to reproduce the problem depends on the elementCount
of the test-array, and eventually some system dependent factors; see
reproduce code)
- If you excecute the script some more times again, someimes the memory
is freed and memory usage is about 10MB again, but after some further
requests, the memory is NOT freed again.
Because of the last point, I think, it is not a memory leak. I also
compiled PHP as debug version and there where no memory leaks reported
(with report_memleaks = On).
But I still think, the consumed memory should be completely freed after
_each_ request. If this is a feature, because something is cached, it
requires a maximum of the cache size. 20-30MB per child is definitely
too much.
If you put an echo memory_get_peak_usage(true); at the beginning of
the script, you will see, that PHP claims to use only about 200-300 KB
at every script start time. It doesn't report the 20-30MB that it
consumes since the last execution.
I tested this with an array, but the problem can, of course, be deeper
in the new memory management of PHP 5.2
Reproduce code:
---
?php
// elementCount: Count of elements which are created in the test
array:
// - a count of 20 demonstrates the problem at best on my
machine
// - a count of 10 or lesser reproduces the problem too, but you
need more
// calls of the script (browser refreshes) until the problem
occurs
// - with a count of 40 or more I couldn't reproduce the
problem,
// there it works fine
// I couldn't figure out exactly, on which factors this count depends
on, but
// it _seems_ to be not machine dependent, but play around with it.
// Note also, that the count of array elements is important, not the
// size of their keys or values.
$elementCount = 20;
for ($i = 0; $i $elementCount; $i++) {
$variables[$i] = 'x';
}
// Even when you unset each array-element manually, the problem
occurs ...
//for ($i = 0; $i $elementCount; $i++) {
// unset($variables[$i]);
//}
// ... and/or if you unset the array itself ...
//unset($variables);
// ... but it does not occur, when you put the unset directly in the
first
// for-loop, that the variable will be unset immediately. Only a
small amount
// of memory is required for the whole request - so PHP can't forgot
to free
// many memory.
?
Expected result:
see Description: All memory being freed after execution of a PHP
script.
Actual result:
--
see Description: Not all memory is freed under some circumstances
after script execution.
--
Edit this bug
#41713 [Opn]: Persistent memory consumption
ID: 41713
User updated by: mplomer at gmx dot de
Reported By: mplomer at gmx dot de
Status: Open
Bug Type: *General Issues
-Operating System: Windows, ev. Linux
+Operating System: Windows
PHP Version: 5.2.3
New Comment:
I tested this under Linux today, and I could not reproduce it here.
Apache's memory consumption is ~10MB after each request, regardless of
the elementCount of the test-array. It seems to be a Windows specific
problem.
I compiled PHP under Linux without and with Thread-Safety
(--enable-maintainer-zts) enabled (because under Windows this is
activated), but it seems this has no influence.
Previous Comments:
[2007-06-16 16:48:04] mplomer at gmx dot de
Description:
When using php arrays with a lot of entries (about 20), I figured
out the following problem: PHP sometimes doesn't free all used memory
after completing the request. Apache uses under some circumstances 20-30
MB more RAM after the request. The problem is that this happens per
child. If an Apache runs with 64 threads, it is possible, that httpd.exe
consumes persistently 300-600 MB of RAM, even without any active
request.
Reproduce environment:
- I tested it under an Apache (1.3 and 2.2) environment unter Windows
(XP) (I didn't test it under Linux yet)
- Used PHP-Version: 5.2.3 - the problem was introduced with PHP 5.2.
With PHP 5.1.6 the problem does not appear (but I noticed, that PHP
5.1.6's memory management is much slower than the new one :-)
- Set ThreadsPerChild to 1 in httpd.conf to make sure, you hit always
the same PHP instance and avoid any constraints
Reproduce procedure:
- Freshly start your 1-thread-Apache [It will consume about 10 MB]
- Execute the following script [Memory usage will grow to ~50-60 MB,
and after execution memory usage shrinks back to ~10 MB again ... works
fine so long]
- Execute the script again 2 or more times [... and surprisingly Apache
consumes about 35MB after the request is complete!] (The number of
executions you need to reproduce the problem depends on the elementCount
of the test-array, and eventually some system dependent factors; see
reproduce code)
- If you excecute the script some more times again, someimes the memory
is freed and memory usage is about 10MB again, but after some further
requests, the memory is NOT freed again.
Because of the last point, I think, it is not a memory leak. I also
compiled PHP as debug version and there where no memory leaks reported
(with report_memleaks = On).
But I still think, the consumed memory should be completely freed after
_each_ request. If this is a feature, because something is cached, it
requires a maximum of the cache size. 20-30MB per child is definitely
too much.
If you put an echo memory_get_peak_usage(true); at the beginning of
the script, you will see, that PHP claims to use only about 200-300 KB
at every script start time. It doesn't report the 20-30MB that it
consumes since the last execution.
I tested this with an array, but the problem can, of course, be deeper
in the new memory management of PHP 5.2
Reproduce code:
---
?php
// elementCount: Count of elements which are created in the test
array:
// - a count of 20 demonstrates the problem at best on my
machine
// - a count of 10 or lesser reproduces the problem too, but you
need more
// calls of the script (browser refreshes) until the problem
occurs
// - with a count of 40 or more I couldn't reproduce the
problem,
// there it works fine
// I couldn't figure out exactly, on which factors this count depends
on, but
// it _seems_ to be not machine dependent, but play around with it.
// Note also, that the count of array elements is important, not the
// size of their keys or values.
$elementCount = 20;
for ($i = 0; $i $elementCount; $i++) {
$variables[$i] = 'x';
}
// Even when you unset each array-element manually, the problem
occurs ...
//for ($i = 0; $i $elementCount; $i++) {
// unset($variables[$i]);
//}
// ... and/or if you unset the array itself ...
//unset($variables);
// ... but it does not occur, when you put the unset directly in the
first
// for-loop, that the variable will be unset immediately. Only a
small amount
// of memory is required for the whole request - so PHP can't forgot
to free
// many memory.
?
Expected result:
see Description: All memory being freed after execution of a PHP
script.
Actual result:
--
see Description: Not all memory is freed under some circumstances
after script execution.
--
Edit this bug report at http://bugs.php.net/?id=41713edit=1
#41713 [NEW]: Persistent memory consumption
From: mplomer at gmx dot de
Operating system: Windows, ev. Linux
PHP version: 5.2.3
PHP Bug Type: *General Issues
Bug description: Persistent memory consumption
Description:
When using php arrays with a lot of entries (about 20), I figured out
the following problem: PHP sometimes doesn't free all used memory after
completing the request. Apache uses under some circumstances 20-30 MB more
RAM after the request. The problem is that this happens per child. If an
Apache runs with 64 threads, it is possible, that httpd.exe consumes
persistently 300-600 MB of RAM, even without any active request.
Reproduce environment:
- I tested it under an Apache (1.3 and 2.2) environment unter Windows (XP)
(I didn't test it under Linux yet)
- Used PHP-Version: 5.2.3 - the problem was introduced with PHP 5.2. With
PHP 5.1.6 the problem does not appear (but I noticed, that PHP 5.1.6's
memory management is much slower than the new one :-)
- Set ThreadsPerChild to 1 in httpd.conf to make sure, you hit always the
same PHP instance and avoid any constraints
Reproduce procedure:
- Freshly start your 1-thread-Apache [It will consume about 10 MB]
- Execute the following script [Memory usage will grow to ~50-60 MB, and
after execution memory usage shrinks back to ~10 MB again ... works fine so
long]
- Execute the script again 2 or more times [... and surprisingly Apache
consumes about 35MB after the request is complete!] (The number of
executions you need to reproduce the problem depends on the elementCount of
the test-array, and eventually some system dependent factors; see reproduce
code)
- If you excecute the script some more times again, someimes the memory is
freed and memory usage is about 10MB again, but after some further
requests, the memory is NOT freed again.
Because of the last point, I think, it is not a memory leak. I also
compiled PHP as debug version and there where no memory leaks reported
(with report_memleaks = On).
But I still think, the consumed memory should be completely freed after
_each_ request. If this is a feature, because something is cached, it
requires a maximum of the cache size. 20-30MB per child is definitely too
much.
If you put an echo memory_get_peak_usage(true); at the beginning of the
script, you will see, that PHP claims to use only about 200-300 KB at every
script start time. It doesn't report the 20-30MB that it consumes since the
last execution.
I tested this with an array, but the problem can, of course, be deeper in
the new memory management of PHP 5.2
Reproduce code:
---
?php
// elementCount: Count of elements which are created in the test array:
// - a count of 20 demonstrates the problem at best on my machine
// - a count of 10 or lesser reproduces the problem too, but you
need more
// calls of the script (browser refreshes) until the problem occurs
// - with a count of 40 or more I couldn't reproduce the problem,
// there it works fine
// I couldn't figure out exactly, on which factors this count depends
on, but
// it _seems_ to be not machine dependent, but play around with it.
// Note also, that the count of array elements is important, not the
// size of their keys or values.
$elementCount = 20;
for ($i = 0; $i $elementCount; $i++) {
$variables[$i] = 'x';
}
// Even when you unset each array-element manually, the problem occurs
...
//for ($i = 0; $i $elementCount; $i++) {
// unset($variables[$i]);
//}
// ... and/or if you unset the array itself ...
//unset($variables);
// ... but it does not occur, when you put the unset directly in the
first
// for-loop, that the variable will be unset immediately. Only a small
amount
// of memory is required for the whole request - so PHP can't forgot to
free
// many memory.
?
Expected result:
see Description: All memory being freed after execution of a PHP script.
Actual result:
--
see Description: Not all memory is freed under some circumstances after
script execution.
--
Edit bug report at http://bugs.php.net/?id=41713edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41713r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41713r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41713r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41713r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41713r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41713r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41713r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41713r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41713r=support
Expected behavior:http://bugs.php.net/fix.php?id=41713r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41713r
#34945 [Opn]: exec(): Problem with quotes in commandline
ID: 34945
User updated by: mplomer at gmx dot de
Reported By: mplomer at gmx dot de
Status: Open
Bug Type: Feature/Change Request
Operating System: WinXP
PHP Version: 5CVS-2005-10-21 (snap)
New Comment:
cmd.exe /C accepts only two quotes in a commandline. If there are more,
then the first and the last quote is removed.
This makes it impossible to pass commandlines like:
C:/Program Files/bla/bla.exe c:/my files/bla.txt
So it is IMHO the best way, if we create an option to bypass the
command-interpreter.
Previous Comments:
[2005-10-21 14:58:25] cspeer at gmx dot de
I have the same problem. I have also no solution to execute commands
with many quotes.
[2005-10-21 14:18:37] mplomer at gmx dot de
Sure, it's not directly a Bug in PHP, but it's a feature-request to
workaround a bug/feature of cmd.exe:
We need a possibility to bypass the command-interpreter for execution
of commands, since cmd.exe can't execute it complete correctly.
Or someone finds a solution to escape quotes correctly. I will check
this out over the weekend ;-)
[2005-10-21 12:58:36] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
[2005-10-21 12:54:39] mplomer at gmx dot de
Description:
If i have a complicated commandline with quotes and spaces in it, and
pass it to exec(), system(), ..., then i get under Windows path or
filename not found despite the filenames are correct.
The Problem is the following:
PHP starts a command over the command-interpreter by prefixing the
commandline with cmd.exe /c .
Test in DOS-Box:
If I enter the command in a DOS-Box, the result is ok, but if I
prefix it with cmd.exe /c , then i get the same failure as in PHP.
If you read the manpage (cmd.exe /?), there is a hint, that
cmd.exe /c has problems with quotes. And IMHO there is no way to
escape theese quotes.
My solutions are:
- Someone finds a way to escape quotes for cmd.exe
- A new Parameter for system()/exec()/...
- ... or better: A php.ini-setting, ... which controls, if the command
is executed over the shell, or executed directly.
Reproduce code:
---
system('D:\Program Files\fop\fop.bat path with blanks/to/bla.fo
output path/bla.pdf');
Expected result:
Successful execution.
Actual result:
--
cmd.exe says: path/file not found
--
Edit this bug report at http://bugs.php.net/?id=34945edit=1
#34945 [NEW]: exec(): Problem with quotes in commandline
From: mplomer at gmx dot de
Operating system: WinXP
PHP version: 5CVS-2005-10-21 (snap)
PHP Bug Type: Program Execution
Bug description: exec(): Problem with quotes in commandline
Description:
If i have a complicated commandline with quotes and spaces in it, and pass
it to exec(), system(), ..., then i get under Windows path or filename not
found despite the filenames are correct.
The Problem is the following:
PHP starts a command over the command-interpreter by prefixing the
commandline with cmd.exe /c .
Test in DOS-Box:
If I enter the command in a DOS-Box, the result is ok, but if I prefix
it with cmd.exe /c , then i get the same failure as in PHP.
If you read the manpage (cmd.exe /?), there is a hint, that cmd.exe
/c has problems with quotes. And IMHO there is no way to escape theese
quotes.
My solutions are:
- Someone finds a way to escape quotes for cmd.exe
- A new Parameter for system()/exec()/...
- ... or better: A php.ini-setting, ... which controls, if the command is
executed over the shell, or executed directly.
Reproduce code:
---
system('D:\Program Files\fop\fop.bat path with blanks/to/bla.fo
output path/bla.pdf');
Expected result:
Successful execution.
Actual result:
--
cmd.exe says: path/file not found
--
Edit bug report at http://bugs.php.net/?id=34945edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34945r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34945r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34945r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34945r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34945r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34945r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34945r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34945r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34945r=support
Expected behavior: http://bugs.php.net/fix.php?id=34945r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34945r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34945r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34945r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34945r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34945r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34945r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34945r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34945r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34945r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34945r=mysqlcfg
#34945 [Bgs-Opn]: exec(): Problem with quotes in commandline
ID: 34945
User updated by: mplomer at gmx dot de
Reported By: mplomer at gmx dot de
-Status: Bogus
+Status: Open
Bug Type: Program Execution
Operating System: WinXP
PHP Version: 5CVS-2005-10-21 (snap)
New Comment:
Sure, it's not directly a Bug in PHP, but it's a feature-request to
workaround a bug/feature of cmd.exe:
We need a possibility to bypass the command-interpreter for execution
of commands, since cmd.exe can't execute it complete correctly.
Or someone finds a solution to escape quotes correctly. I will check
this out over the weekend ;-)
Previous Comments:
[2005-10-21 12:58:36] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
[2005-10-21 12:54:39] mplomer at gmx dot de
Description:
If i have a complicated commandline with quotes and spaces in it, and
pass it to exec(), system(), ..., then i get under Windows path or
filename not found despite the filenames are correct.
The Problem is the following:
PHP starts a command over the command-interpreter by prefixing the
commandline with cmd.exe /c .
Test in DOS-Box:
If I enter the command in a DOS-Box, the result is ok, but if I
prefix it with cmd.exe /c , then i get the same failure as in PHP.
If you read the manpage (cmd.exe /?), there is a hint, that
cmd.exe /c has problems with quotes. And IMHO there is no way to
escape theese quotes.
My solutions are:
- Someone finds a way to escape quotes for cmd.exe
- A new Parameter for system()/exec()/...
- ... or better: A php.ini-setting, ... which controls, if the command
is executed over the shell, or executed directly.
Reproduce code:
---
system('D:\Program Files\fop\fop.bat path with blanks/to/bla.fo
output path/bla.pdf');
Expected result:
Successful execution.
Actual result:
--
cmd.exe says: path/file not found
--
Edit this bug report at http://bugs.php.net/?id=34945edit=1
#29007 [NEW]: glob() nomatch returns false
From: mplomer at gmx dot de Operating system: WinXP PHP version: 5CVS-2004-07-04 (dev) PHP Bug Type: Directory function related Bug description: glob() nomatch returns false Description: Same as Bug# 28649. It seems to be fixed only in 4.x-CVS With the actual 5.0-CVS-Snapshot I have the same Problem. Reproduce code: --- php -r 'var_dump(glob(abcdefg));' Expected result: an empty array() Actual result: -- bool(false) -- Edit bug report at http://bugs.php.net/?id=29007edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29007r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29007r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29007r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29007r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29007r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29007r=needscript Try newer version: http://bugs.php.net/fix.php?id=29007r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29007r=support Expected behavior: http://bugs.php.net/fix.php?id=29007r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29007r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29007r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29007r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29007r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29007r=dst IIS Stability: http://bugs.php.net/fix.php?id=29007r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29007r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29007r=float
