[PHP-BUG] Bug #64503 [NEW]: Compilation fails with error: conflicting types for 'zendparse'
From: stormbyte at gmail dot com Operating system: Gentoo PHP version: 5.5.0beta1 Package: Compile Failure Bug Type: Bug Bug description:Compilation fails with error: conflicting types for 'zendparse' Description: These are the last lines for compile log output: /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/Zend/zend_language_parser.h:331:5: error: conflicting types for 'zendparse' In file included from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/Zend/zend_globals.h:28:0, from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/Zend/zend_compile.h:418, from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/Zend/zend_modules.h:26, from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/Zend/zend_API.h:26, from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/main/php.h:38, from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/ext/tokenizer/tokenizer_data.c:26: /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/Zend/zend_globals_macros.h:35:5: note: previous declaration of 'zendparse' was here distcc[20503] ERROR: compile /var/tmp/portage/dev-lang/php-5.5.0_beta1- r2/work/sapis-build/cli/ext/tokenizer/tokenizer_data.c on localhost failed make: *** [ext/tokenizer/tokenizer_data.lo] Error 1 make: *** Waiting for unfinished jobs In file included from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/ext/tokenizer/tokenizer.c:33:0: /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/Zend/zend_language_parser.h:331:5: error: conflicting types for 'zendparse' In file included from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/Zend/zend_globals.h:28:0, from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/Zend/zend_compile.h:418, from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/Zend/zend_modules.h:26, from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/Zend/zend_API.h:26, from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/main/php.h:38, from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/ext/tokenizer/tokenizer.c:25: /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis- build/cli/Zend/zend_globals_macros.h:35:5: note: previous declaration of 'zendparse' was here distcc[20491] ERROR: compile /var/tmp/portage/dev-lang/php-5.5.0_beta1- r2/work/sapis-build/cli/ext/tokenizer/tokenizer.c on localhost failed make: *** [ext/tokenizer/tokenizer.lo] Error 1 Test script: --- In my case, just emerge php OR try to compile it Expected result: Compilation successful Actual result: -- Compile error -- Edit bug report at https://bugs.php.net/bug.php?id=64503edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64503r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64503r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64503r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64503r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64503r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64503r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64503r=needscript Try newer version: https://bugs.php.net/fix.php?id=64503r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64503r=support Expected behavior: https://bugs.php.net/fix.php?id=64503r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64503r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64503r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64503r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64503r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64503r=dst IIS Stability: https://bugs.php.net/fix.php?id=64503r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64503r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64503r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64503r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64503r=mysqlcfg
Bug #62524 [Com]: fopen follows redirects for non-3xx statuses
Edit report at https://bugs.php.net/bug.php?id=62524edit=1
ID: 62524
Comment by: stormbyte at gmail dot com
Reported by:mike dot hall at twistdigital dot co dot uk
Summary:fopen follows redirects for non-3xx statuses
Status: Closed
Type: Bug
Package:Streams related
Operating System: Ubuntu 12.04
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
I saw git diff, and 308 permanent redirect is missing in the code:
/* we only care about Location for 300, 301, 302, 303 and 307 */
Since 308 is Permanent Redirect in http 1.1, it should be included also to be
followed and not ignored, otherwise, this bug might happen again on some
servers.
Previous Comments:
[2013-01-29 08:29:32] s...@php.net
Automatic comment on behalf of stas
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=5382e156f925603ef0f65b9cc4fed29cbe2dce9b
Log: Fix bug #62524, only follow redirects in file streams for 3xx HTTP statuses
[2012-11-25 02:15:33] wes at serverdensity dot com
I've submitted a patch for this via Github pull request:
https://github.com/php/php-src/pull/236
[2012-07-12 14:34:17] Sjon at hortensius dot net
A more complete example confirms this behavior:
I also fixed some syntax errors
?php
header('Location: http://php.net', true, 201);
if (isset($_GET['waa']))
return;
$context = stream_context_create(array(
http = array(
method = POST,
header = Content-Length: 13,
content = {\foo\:\bar\},
),
));
$fp = fopen('http://'.$_SERVER['SERVER_NAME']. $_SERVER['PHP_SELF'] .'?waa=1',
'r', null, $context);
print(stream_get_contents($fp));
[2012-07-10 16:00:52] mike dot hall at twistdigital dot co dot uk
Description:
The HTTP location header can either be used to direct the user to another
resource (when accompanied by a 3xx status code) or to inform the user of the
location of the document they just created (with a 2xx) status code.
It doesn't make sense to treat the location header as a redirect in the second
context - the location header indicates a redirect only when accompanied by a
3xx
status code.
Currently, PHP follows Location headers as if they are redirects regardless of
the returned status code.
Test script:
---
$context = stream_context_create([
http = [
method = POST
header = Content-Length: 13
content = {\foo\:\bar\},
],
]);
// Returns HTTP/1.1 201 Created
// Location: http://example.com/mydb/documentid
//
// {status:ok}
$fp = fopen('http://example.com/mydb', 'r', null, $context);
$data = stream_get_contents($fp);
list($headers, $body) = explode(\r\n\r\n, $data, 2);
echo $body;
Expected result:
{status:ok}
Actual result:
--
{foo:bar}
--
Edit this bug report at https://bugs.php.net/bug.php?id=62524edit=1
Bug #62524 [Com]: fopen follows redirects for non-3xx statuses
Edit report at https://bugs.php.net/bug.php?id=62524edit=1
ID: 62524
Comment by: stormbyte at gmail dot com
Reported by:mike dot hall at twistdigital dot co dot uk
Summary:fopen follows redirects for non-3xx statuses
Status: Closed
Type: Bug
Package:Streams related
Operating System: Ubuntu 12.04
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
I attach a git diff with proposed changes:
diff --git a/ext/standard/http_fopen_wrapper.c
b/ext/standard/http_fopen_wrapper.c
index 870f904..a3f193b 100644
--- a/ext/standard/http_fopen_wrapper.c
+++ b/ext/standard/http_fopen_wrapper.c
@@ -731,9 +731,9 @@ finish:
http_header_line[http_header_line_length] = '\0';
if (!strncasecmp(http_header_line, Location: , 10)) {
- /* we only care about Location for 300, 301,
302, 303 and 307 */
+ /* we only care about Location for 300, 301,
302, 303, 307 and 308 */
/* see
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1 */
- if ((response_code = 300 response_code
304 || 307 == response_code) context
php_stream_context_get_option(context, http, follow_location, tmpzval) ==
SUCCESS) {
+ if ((response_code = 300 response_code
304 || 307 == response_code || 308 == response_code) context
php_stream_context_get_option(context, http, follow_location, tmpzval) ==
SUCCESS) {
SEPARATE_ZVAL(tmpzval);
convert_to_long_ex(tmpzval);
follow_location = Z_LVAL_PP(tmpzval);
Previous Comments:
[2013-03-05 07:27:02] stormbyte at gmail dot com
I saw git diff, and 308 permanent redirect is missing in the code:
/* we only care about Location for 300, 301, 302, 303 and 307 */
Since 308 is Permanent Redirect in http 1.1, it should be included also to be
followed and not ignored, otherwise, this bug might happen again on some
servers.
[2013-01-29 08:29:32] s...@php.net
Automatic comment on behalf of stas
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=5382e156f925603ef0f65b9cc4fed29cbe2dce9b
Log: Fix bug #62524, only follow redirects in file streams for 3xx HTTP statuses
[2012-11-25 02:15:33] wes at serverdensity dot com
I've submitted a patch for this via Github pull request:
https://github.com/php/php-src/pull/236
[2012-07-12 14:34:17] Sjon at hortensius dot net
A more complete example confirms this behavior:
I also fixed some syntax errors
?php
header('Location: http://php.net', true, 201);
if (isset($_GET['waa']))
return;
$context = stream_context_create(array(
http = array(
method = POST,
header = Content-Length: 13,
content = {\foo\:\bar\},
),
));
$fp = fopen('http://'.$_SERVER['SERVER_NAME']. $_SERVER['PHP_SELF'] .'?waa=1',
'r', null, $context);
print(stream_get_contents($fp));
[2012-07-10 16:00:52] mike dot hall at twistdigital dot co dot uk
Description:
The HTTP location header can either be used to direct the user to another
resource (when accompanied by a 3xx status code) or to inform the user of the
location of the document they just created (with a 2xx) status code.
It doesn't make sense to treat the location header as a redirect in the second
context - the location header indicates a redirect only when accompanied by a
3xx
status code.
Currently, PHP follows Location headers as if they are redirects regardless of
the returned status code.
Test script:
---
$context = stream_context_create([
http = [
method = POST
header = Content-Length: 13
content = {\foo\:\bar\},
],
]);
// Returns HTTP/1.1 201 Created
// Location: http://example.com/mydb/documentid
//
// {status:ok}
$fp = fopen('http://example.com/mydb', 'r', null, $context);
$data = stream_get_contents($fp);
list($headers, $body) = explode(\r\n\r\n, $data, 2);
echo $body;
Expected result:
{status:ok}
Actual result:
--
{foo:bar}
--
Edit this bug report at https://bugs.php.net/bug.php?id=62524edit=1
[PHP-BUG] Req #64266 [NEW]: Pass arrays as reference by default
From: stormbyte at gmail dot com
Operating system: Linux
PHP version: 5.4.11
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:Pass arrays as reference by default
Description:
One of major benefits from PHP is that it is very close to C/C++ style, so
it is its functions and coding style (very similar for, while and those
constructs) so if you come from C/C++ world, you have it easy.
To keep this consistence I suggest, as well as C/C++ does, passing arrays
as reference in function arguments by default, or at least an option to
behave like that.
For me, it does not make much sense to follow C/C++ coding styles and
behaviour, while not following that behaviour.
Furthermore, objects are already passed by reference as default, so why not
arrays? IMHO I think that inconsistence may confuse programmers.
Test script:
---
function foo($arr) {
array_push($arr, test);
}
function bar($arr) {
array_push($arr, test);
}
$a=array();
foo($a);
//$a is empty
bar($a);
//$a[0]=test
Expected result:
To be consistent with the rest behaviour of imitating C/C++ and pass
arrays as reference automatically as well as objects are.
Also, it may be a performance gain by doing that (which is one of the
reasons in C world it is that way)
--
Edit bug report at https://bugs.php.net/bug.php?id=64266edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64266r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64266r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64266r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64266r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64266r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64266r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64266r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64266r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64266r=support
Expected behavior: https://bugs.php.net/fix.php?id=64266r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64266r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64266r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64266r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64266r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64266r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64266r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64266r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64266r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64266r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64266r=mysqlcfg
Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556edit=1 ID: 18556 Comment by: stormbyte at gmail dot com Reported by:spud at nothingness dot org Summary:Setting locale to 'tr_TR' lowercases class names Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Linux (RedHat 7.2) PHP Version:5CVS, 4CVS (2005-10-04) Assigned To:dmitry Block user comment: N Private report: N New Comment: It is not fixed in 5.4.4 as some stated above. Tested with php 5.4.4 Testcase: ?php echo 'Starting...br /'; $class = 'PharFileInfo'; echo 'Locale: '.setlocale(LC_ALL, '0').br /; echo $class exists? .var_export(class_exists($class), true).br /; echo 'Locale: '.setlocale(LC_ALL, 'tr_TR.UTF-8').br /; echo $class exists? .var_export(class_exists($class), true).br /; ? Output with nginx+spawnFCGI: Starting... Locale: C PharFileInfo exists? true Locale: tr_TR.UTF-8 PharFileInfo exists? false Output with cli (php -f test.php): Starting...br /Locale: Cbr /PharFileInfo exists? truebr /Locale: tr_TR.UTF-8br /PharFileInfo exists? falsebr / Previous Comments: [2012-07-03 09:58:31] maar...@php.net Appears to be fixed since = 5.4.0 See http://3v4l.org/lahi5 for proof: --- Output for 5.4.0 - 5.4.4 Instantiating an infoBlob with a lowercase ibrFoobrInstantiating an InfoBlob with an uppercase IbrFoo Output for 5.0.0 - 5.0.5, 5.1.0 - 5.1.6, 5.2.0 - 5.2.17, 5.3.0 - 5.3.14 Instantiating an infoBlob with a lowercase ibrFoobrInstantiating an InfoBlob with an uppercase Ibr Fatal error: Class 'InfoBlob' not found in /in/lahi5 on line 25 Process exited with code 255. --- Can't find it in the changelogs though. [2012-07-03 09:02:01] shevegen at gmail dot com There are other languages one could use, other than PHP. [2012-07-02 11:42:50] bobx at bob dot com hahaha yeah PHP is garbage [2012-05-15 20:54:08] inet dot alper at gmail dot com https://github.com/php/php-src/pull/79 this patch does not break other locales, check it out. [2012-05-05 15:33:55] wim at powerassist dot nl Sorry, I was to quick to comment. I see that there's an internal mailing going on. 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 https://bugs.php.net/bug.php?id=18556 -- Edit this bug report at https://bugs.php.net/bug.php?id=18556edit=1
Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556edit=1 ID: 18556 Comment by: stormbyte at gmail dot com Reported by:spud at nothingness dot org Summary:Setting locale to 'tr_TR' lowercases class names Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Linux (RedHat 7.2) PHP Version:5CVS, 4CVS (2005-10-04) Assigned To:dmitry Block user comment: N Private report: N New Comment: maar...@php.net: They don't seem to be running vanilla PHP installations. I've compiled php-5.4.4 from Gentoo and do not appear to be fixed to me, even in 5.4.4. Can you try on a vanilla PHP? Previous Comments: [2012-07-03 16:42:22] stormbyte at gmail dot com It is not fixed in 5.4.4 as some stated above. Tested with php 5.4.4 Testcase: ?php echo 'Starting...br /'; $class = 'PharFileInfo'; echo 'Locale: '.setlocale(LC_ALL, '0').br /; echo $class exists? .var_export(class_exists($class), true).br /; echo 'Locale: '.setlocale(LC_ALL, 'tr_TR.UTF-8').br /; echo $class exists? .var_export(class_exists($class), true).br /; ? Output with nginx+spawnFCGI: Starting... Locale: C PharFileInfo exists? true Locale: tr_TR.UTF-8 PharFileInfo exists? false Output with cli (php -f test.php): Starting...br /Locale: Cbr /PharFileInfo exists? truebr /Locale: tr_TR.UTF-8br /PharFileInfo exists? falsebr / [2012-07-03 09:58:31] maar...@php.net Appears to be fixed since = 5.4.0 See http://3v4l.org/lahi5 for proof: --- Output for 5.4.0 - 5.4.4 Instantiating an infoBlob with a lowercase ibrFoobrInstantiating an InfoBlob with an uppercase IbrFoo Output for 5.0.0 - 5.0.5, 5.1.0 - 5.1.6, 5.2.0 - 5.2.17, 5.3.0 - 5.3.14 Instantiating an infoBlob with a lowercase ibrFoobrInstantiating an InfoBlob with an uppercase Ibr Fatal error: Class 'InfoBlob' not found in /in/lahi5 on line 25 Process exited with code 255. --- Can't find it in the changelogs though. [2012-07-03 09:02:01] shevegen at gmail dot com There are other languages one could use, other than PHP. [2012-07-02 11:42:50] bobx at bob dot com hahaha yeah PHP is garbage [2012-05-15 20:54:08] inet dot alper at gmail dot com https://github.com/php/php-src/pull/79 this patch does not break other locales, check it out. 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 https://bugs.php.net/bug.php?id=18556 -- Edit this bug report at https://bugs.php.net/bug.php?id=18556edit=1
Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556edit=1
ID: 18556
Comment by: stormbyte at gmail dot com
Reported by:spud at nothingness dot org
Summary:Setting locale to 'tr_TR' lowercases class names
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: Linux (RedHat 7.2)
PHP Version:5CVS, 4CVS (2005-10-04)
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The problem:
?php
setlocale(LC_ALL, 'tr_TR.UTF-8');
echo strtolower('THIS IS JUST A TEST');
?
output:
thIs Is just a test
So if it is using the same function internally to do the tolower on class
names, it will not find them.
A workarround would be use toupper instead of tolower in zend_internal
namespace handling, despite the correct fix would be to use independent
identifyers (??)
Previous Comments:
[2012-07-03 16:53:08] stormbyte at gmail dot com
maar...@php.net:
They don't seem to be running vanilla PHP installations.
I've compiled php-5.4.4 from Gentoo and do not appear to be fixed to me, even
in 5.4.4.
Can you try on a vanilla PHP?
[2012-07-03 16:42:22] stormbyte at gmail dot com
It is not fixed in 5.4.4 as some stated above.
Tested with php 5.4.4
Testcase:
?php
echo 'Starting...br /';
$class = 'PharFileInfo';
echo 'Locale: '.setlocale(LC_ALL, '0').br /;
echo $class exists? .var_export(class_exists($class), true).br /;
echo 'Locale: '.setlocale(LC_ALL, 'tr_TR.UTF-8').br /;
echo $class exists? .var_export(class_exists($class), true).br /;
?
Output with nginx+spawnFCGI:
Starting...
Locale: C
PharFileInfo exists? true
Locale: tr_TR.UTF-8
PharFileInfo exists? false
Output with cli (php -f test.php):
Starting...br /Locale: Cbr /PharFileInfo exists? truebr /Locale:
tr_TR.UTF-8br /PharFileInfo exists? falsebr /
[2012-07-03 09:58:31] maar...@php.net
Appears to be fixed since = 5.4.0
See http://3v4l.org/lahi5 for proof:
---
Output for 5.4.0 - 5.4.4
Instantiating an infoBlob with a lowercase ibrFoobrInstantiating an
InfoBlob with an uppercase IbrFoo
Output for 5.0.0 - 5.0.5, 5.1.0 - 5.1.6, 5.2.0 - 5.2.17, 5.3.0 - 5.3.14
Instantiating an infoBlob with a lowercase ibrFoobrInstantiating an
InfoBlob with an uppercase Ibr Fatal error: Class 'InfoBlob' not found in
/in/lahi5 on line 25
Process exited with code 255.
---
Can't find it in the changelogs though.
[2012-07-03 09:02:01] shevegen at gmail dot com
There are other languages one could use, other than PHP.
[2012-07-02 11:42:50] bobx at bob dot com
hahaha yeah PHP is garbage
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
https://bugs.php.net/bug.php?id=18556
--
Edit this bug report at https://bugs.php.net/bug.php?id=18556edit=1
[PHP-BUG] Bug #61395 [NEW]: Possible memory leak (in array copy?)
From:
Operating system: Linux
PHP version: 5.4.0
Package: *General Issues
Bug Type: Bug
Bug description:Possible memory leak (in array copy?)
Description:
I did found on the internet some code to have test and measure memory
usage. After tweaking it a bit, I discovered that when finishes (and
unsetting all vars), PHP does not go back to initial memory usage which
seems a memory leak.
This is the output the test script produces:
Note that memory usave in Stage 1, should be equal to memory usage in Stage
8 theoretically.
Test script:
---
?php
echo Stage 1: Mem usage is: , memory_get_usage(), \n;
$arr = array();
for ($i = 0; $i 10; ++$i) {
$arr[] = rand();
}
echo Stage 2: Mem usage is: , memory_get_usage(), \n;
$foo = 1;
$bar = 2;
echo Stage 3: Mem usage is: , memory_get_usage(), \n;
$foo = $arr;
$bar = $arr;
echo Stage 4: Mem usage is: , memory_get_usage(), \n;
$arr = array();
echo Stage 5: Mem usage is: , memory_get_usage(), \n;
$bar[] = hello, world;
echo Stage 6: Mem usage is: , memory_get_usage(), \n;
$foo = array();
echo Stage 7: Mem usage is: , memory_get_usage(), \n;
unset($arr);
unset($foo);
unset($bar);
flush();
echo Stage 8: Mem usage is: , memory_get_usage(), \n;
?
Expected result:
Expected output:
PHP 5.4.0:
Stage 1: Mem usage is: 234104
Stage 2: Mem usage is: 14883160
Stage 3: Mem usage is: 14883432
Stage 4: Mem usage is: 14883336
Stage 5: Mem usage is: 14883472
Stage 6: Mem usage is: 24732360
Stage 7: Mem usage is: 14883736
Stage 8: Mem usage is: 234104
Actual result:
--
PHP 5.4.0:
Stage 1: Mem usage is: 234104
Stage 2: Mem usage is: 14883160
Stage 3: Mem usage is: 14883432
Stage 4: Mem usage is: 14883336
Stage 5: Mem usage is: 14883472
Stage 6: Mem usage is: 24732360
Stage 7: Mem usage is: 14883736
Stage 8: Mem usage is: 234240
PHP 5.2.7:
Stage 1: Mem usage is: 95520
Stage 2: Mem usage is: 13945080
Stage 3: Mem usage is: 13945352
Stage 4: Mem usage is: 13945272
Stage 5: Mem usage is: 13945480
Stage 6: Mem usage is: 23794376
Stage 7: Mem usage is: 13945680
Stage 8: Mem usage is: 95656
(Much more memory used in 5.4.0?)
--
Edit bug report at https://bugs.php.net/bug.php?id=61395edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61395r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61395r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61395r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61395r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61395r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61395r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61395r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61395r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61395r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61395r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61395r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61395r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61395r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61395r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61395r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61395r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61395r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61395r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61395r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61395r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61395r=mysqlcfg
Bug #61395 [Opn-Csd]: Possible memory leak (in array copy?)
Edit report at https://bugs.php.net/bug.php?id=61395edit=1
ID: 61395
User updated by:stormbyte at gmail dot com
Reported by:stormbyte at gmail dot com
Summary:Possible memory leak (in array copy?)
-Status: Open
+Status: Closed
Type: Bug
Package:*General Issues
Operating System: Linux
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Forgot to unset($i) a variable and thus the false memory leak. Sorry
Previous Comments:
[2012-03-15 04:43:04] stormbyte at gmail dot com
Description:
I did found on the internet some code to have test and measure memory usage.
After tweaking it a bit, I discovered that when finishes (and unsetting all
vars), PHP does not go back to initial memory usage which seems a memory leak.
This is the output the test script produces:
Note that memory usave in Stage 1, should be equal to memory usage in Stage 8
theoretically.
Test script:
---
?php
echo Stage 1: Mem usage is: , memory_get_usage(), \n;
$arr = array();
for ($i = 0; $i 10; ++$i) {
$arr[] = rand();
}
echo Stage 2: Mem usage is: , memory_get_usage(), \n;
$foo = 1;
$bar = 2;
echo Stage 3: Mem usage is: , memory_get_usage(), \n;
$foo = $arr;
$bar = $arr;
echo Stage 4: Mem usage is: , memory_get_usage(), \n;
$arr = array();
echo Stage 5: Mem usage is: , memory_get_usage(), \n;
$bar[] = hello, world;
echo Stage 6: Mem usage is: , memory_get_usage(), \n;
$foo = array();
echo Stage 7: Mem usage is: , memory_get_usage(), \n;
unset($arr);
unset($foo);
unset($bar);
flush();
echo Stage 8: Mem usage is: , memory_get_usage(), \n;
?
Expected result:
Expected output:
PHP 5.4.0:
Stage 1: Mem usage is: 234104
Stage 2: Mem usage is: 14883160
Stage 3: Mem usage is: 14883432
Stage 4: Mem usage is: 14883336
Stage 5: Mem usage is: 14883472
Stage 6: Mem usage is: 24732360
Stage 7: Mem usage is: 14883736
Stage 8: Mem usage is: 234104
Actual result:
--
PHP 5.4.0:
Stage 1: Mem usage is: 234104
Stage 2: Mem usage is: 14883160
Stage 3: Mem usage is: 14883432
Stage 4: Mem usage is: 14883336
Stage 5: Mem usage is: 14883472
Stage 6: Mem usage is: 24732360
Stage 7: Mem usage is: 14883736
Stage 8: Mem usage is: 234240
PHP 5.2.7:
Stage 1: Mem usage is: 95520
Stage 2: Mem usage is: 13945080
Stage 3: Mem usage is: 13945352
Stage 4: Mem usage is: 13945272
Stage 5: Mem usage is: 13945480
Stage 6: Mem usage is: 23794376
Stage 7: Mem usage is: 13945680
Stage 8: Mem usage is: 95656
(Much more memory used in 5.4.0?)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61395edit=1
Bug #61395 [Csd]: Possible memory leak (in array copy?)
Edit report at https://bugs.php.net/bug.php?id=61395edit=1
ID: 61395
User updated by:stormbyte at gmail dot com
Reported by:stormbyte at gmail dot com
Summary:Possible memory leak (in array copy?)
Status: Closed
Type: Bug
Package:*General Issues
Operating System: Linux
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Forgot to unset($i) and thus the false memory leak. But why 5.4.0 still uses
more memory is still a mistery. Sorry.
Previous Comments:
[2012-03-15 04:45:02] stormbyte at gmail dot com
Forgot to unset($i) a variable and thus the false memory leak. Sorry
[2012-03-15 04:43:04] stormbyte at gmail dot com
Description:
I did found on the internet some code to have test and measure memory usage.
After tweaking it a bit, I discovered that when finishes (and unsetting all
vars), PHP does not go back to initial memory usage which seems a memory leak.
This is the output the test script produces:
Note that memory usave in Stage 1, should be equal to memory usage in Stage 8
theoretically.
Test script:
---
?php
echo Stage 1: Mem usage is: , memory_get_usage(), \n;
$arr = array();
for ($i = 0; $i 10; ++$i) {
$arr[] = rand();
}
echo Stage 2: Mem usage is: , memory_get_usage(), \n;
$foo = 1;
$bar = 2;
echo Stage 3: Mem usage is: , memory_get_usage(), \n;
$foo = $arr;
$bar = $arr;
echo Stage 4: Mem usage is: , memory_get_usage(), \n;
$arr = array();
echo Stage 5: Mem usage is: , memory_get_usage(), \n;
$bar[] = hello, world;
echo Stage 6: Mem usage is: , memory_get_usage(), \n;
$foo = array();
echo Stage 7: Mem usage is: , memory_get_usage(), \n;
unset($arr);
unset($foo);
unset($bar);
flush();
echo Stage 8: Mem usage is: , memory_get_usage(), \n;
?
Expected result:
Expected output:
PHP 5.4.0:
Stage 1: Mem usage is: 234104
Stage 2: Mem usage is: 14883160
Stage 3: Mem usage is: 14883432
Stage 4: Mem usage is: 14883336
Stage 5: Mem usage is: 14883472
Stage 6: Mem usage is: 24732360
Stage 7: Mem usage is: 14883736
Stage 8: Mem usage is: 234104
Actual result:
--
PHP 5.4.0:
Stage 1: Mem usage is: 234104
Stage 2: Mem usage is: 14883160
Stage 3: Mem usage is: 14883432
Stage 4: Mem usage is: 14883336
Stage 5: Mem usage is: 14883472
Stage 6: Mem usage is: 24732360
Stage 7: Mem usage is: 14883736
Stage 8: Mem usage is: 234240
PHP 5.2.7:
Stage 1: Mem usage is: 95520
Stage 2: Mem usage is: 13945080
Stage 3: Mem usage is: 13945352
Stage 4: Mem usage is: 13945272
Stage 5: Mem usage is: 13945480
Stage 6: Mem usage is: 23794376
Stage 7: Mem usage is: 13945680
Stage 8: Mem usage is: 95656
(Much more memory used in 5.4.0?)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61395edit=1
