#32553 [NEW]: PHP_STREAM_COPY_ALL set to 2000000
From: ppmm at wuxinan dot net Operating system: Windows XP PHP version: 5.0.4 PHP Bug Type: Filesystem function related Bug description: PHP_STREAM_COPY_ALL set to 200 Description: I noticed this is already discussed in PHP-DEV mailing list. But I want to address it here since this is critical. Many file related functions are affected in php 5.0.4 They stop reading at 2,000,000 bytes. Examples are readfile() and fpassthru(). This is due to this change: RCS file: /repository/php-src/main/php_streams.h,v retrieving revision 1.95 retrieving revision 1.95.2.1 I wouldn't recommend upgrading from 5.0.3 to 5.0.4 if you are unsure about this issue... [ref: Re: [PHP-DEV] Two minor issues in 5.0.4 Antony Dovgal Sun, 27 Mar 2005 03:56:27 -0800 ] -- Edit bug report at http://bugs.php.net/?id=32553edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32553r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32553r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32553r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32553r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32553r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32553r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32553r=needscript Try newer version: http://bugs.php.net/fix.php?id=32553r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32553r=support Expected behavior: http://bugs.php.net/fix.php?id=32553r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32553r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32553r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32553r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32553r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32553r=dst IIS Stability: http://bugs.php.net/fix.php?id=32553r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32553r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32553r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32553r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32553r=mysqlcfg
#30014 [Com]: pathinfo() doesn't handle multibyte path
ID: 30014
Comment by: ppmm at wuxinan dot net
Reported By: cvictor at pchome dot com dot tw
Status: Open
Bug Type: Directory function related
Operating System: Windows XP Pro
PHP Version: 5.0.1
New Comment:
related to bug# 30105
http://bugs.php.net/bug.php?id=30105
Previous Comments:
[2004-09-07 20:26:26] cvictor at pchome dot com dot tw
Description:
pathinfo() doesn't handle pathname in multibyte well. This error can be
reporduced under big5 and utf-8 charset, no matter converting the whole
source php file or using mb_convert_encoding() inline.
This error only occurs when the first character of basename is a
Chinese character.
I didn't recompile PHP bin, and modules used seem not relevent. My
php.ini is adapted from php.ini-recommended. The OS is a Traditional
Chinese version.
Reproduce code:
---
?php
$fp = '/var/©ú²Ó.txt';
var_dump(pathinfo($fp));
$fp = '/var/a©ú²Ó.txt';
var_dump(pathinfo($fp));
?
Expected result:
array(3) {
[dirname]=
string(4) /var
[basename]=
string(8) ©ú²Ó.txt
[extension]=
string(3) txt
}
array(3) {
[dirname]=
string(4) /var
[basename]=
string(8) a©ú²Ó.txt
[extension]=
string(3) txt
}
Actual result:
--
array(3) {
[dirname]=
string(4) /var
[basename]=
string(4) .txt
[extension]=
string(3) txt
}
array(3) {
[dirname]=
string(4) /var
[basename]=
string(8) a©ú²Ó.txt
[extension]=
string(3) txt
}
--
Edit this bug report at http://bugs.php.net/?id=30014edit=1
#30014 [Com]: pathinfo() doesn't handle multibyte path
ID: 30014
Comment by: ppmm at wuxinan dot net
Reported By: cvictor at pchome dot com dot tw
Status: Open
Bug Type: Directory function related
Operating System: Windows XP Pro
PHP Version: 5.0.1
New Comment:
partial summary of bug # 29542 30014 30105:
this bug confirmed to exist on:
simplified chinese windows 2000
traditional chinese windows xp pro
redhat 9 (default rpm's)
this bug confirmed not to exist on:
fedora core 3 test 1 (default rpm's)
english windows xp pro
Previous Comments:
[2004-09-30 03:22:30] ppmm at wuxinan dot net
related to bug# 30105
http://bugs.php.net/bug.php?id=30105
[2004-09-07 20:26:26] cvictor at pchome dot com dot tw
Description:
pathinfo() doesn't handle pathname in multibyte well. This error can be
reporduced under big5 and utf-8 charset, no matter converting the whole
source php file or using mb_convert_encoding() inline.
This error only occurs when the first character of basename is a
Chinese character.
I didn't recompile PHP bin, and modules used seem not relevent. My
php.ini is adapted from php.ini-recommended. The OS is a Traditional
Chinese version.
Reproduce code:
---
?php
$fp = '/var/©ú²Ó.txt';
var_dump(pathinfo($fp));
$fp = '/var/a©ú²Ó.txt';
var_dump(pathinfo($fp));
?
Expected result:
array(3) {
[dirname]=
string(4) /var
[basename]=
string(8) ©ú²Ó.txt
[extension]=
string(3) txt
}
array(3) {
[dirname]=
string(4) /var
[basename]=
string(8) a©ú²Ó.txt
[extension]=
string(3) txt
}
Actual result:
--
array(3) {
[dirname]=
string(4) /var
[basename]=
string(4) .txt
[extension]=
string(3) txt
}
array(3) {
[dirname]=
string(4) /var
[basename]=
string(8) a©ú²Ó.txt
[extension]=
string(3) txt
}
--
Edit this bug report at http://bugs.php.net/?id=30014edit=1
#30105 [Com]: Error of the function basename()
ID: 30105 Comment by: ppmm at wuxinan dot net Reported By: lp at zy165 dot com Status: Open Bug Type: Directory function related Operating System: Linux 9 PHP Version: 5.0.1 New Comment: http://bugs.php.net/bug.php?id=29542 please refer to bug 29542. I am the reporter of that bug. I MISTAKENLY gave the report that this bug has been fixed in 5.0.1, resulting bug 29542 being closed. This bug has NOT been fixed in 5.0.1, and not in snapshot either. Additional information: this bug does not exist on my English windows xp server, but DOES exist on my Chinese windows 2k server. I tried xp with 5.0.1 and didn't find problem, so mistakenly reported it has been fixed. sorry. Seems like this problem is related to non-unicode/unicode platform issue. Previous Comments: [2004-09-16 07:44:25] lp at zy165 dot com Description: I am Chinese. I love linux, php very much. So I do many things using php. But tody, i find an error of the function basename() so that i can't continue writing code by php. The error like this: if the $path in function basename($path) contain the Chinese, then the result will be error. The error appears only in php-5.0.1, before the version it works normally. Please e-mail me after you see the letter, thank you very much. Reproduce code: --- ?php $path=/home/httpd/ÎÒ/°®/Äã.php; //Here the $path means /home/httpd/I/Love/You.php,and I love you is translated to Chinese. $str1=basename ($path,.php); $str2=basename ($path); echo $path.br1:.$str1.br2:.$str2; $path2=/home/httpd/ÎÒ/Love/Äã; $str3=basename ($path2); echo brbr.$path2.br3:.$str3; $path3=/home/httpd/I/Love/Äã; $str4=basename ($path3); echo brbr.$path3.br4:.$str4; ? Expected result: /home/httpd/ÎÒ/°®/Äã.php 1:Äã 2:Äã.php /home/httpd/ÎÒ/Love/Äã 3:Äã /home/httpd/I/Love/Äã 4:Äã Actual result: -- /home/httpd/ÎÒ/°®/Äã.php 1:.php 2:.php /home/httpd/ÎÒ/Love/Äã 3:Love /home/httpd/I/Love/Äã 4:Love -- Edit this bug report at http://bugs.php.net/?id=30105edit=1
#29542 [Fbk-Opn]: basename() has problem in supporting multi-byte chars.
ID: 29542 User updated by: ppmm at wuxinan dot net Reported By: ppmm at wuxinan dot net -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: Windows 2000 Prof. PHP Version: 5.0.0 New Comment: didn't try CVS, but quickly tried 5.0.1 and found no problem. This bug must have been fixed in 5.0.1 already. Thanks. Previous Comments: [2004-09-04 17:16:28] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Works fine here, try the latest snapshot. [2004-08-05 23:42:35] ppmm at wuxinan dot net Description: when path has multi-byte chars, basename() does not return correct file basename. I did not have this problem in PHP 4.3.7. In the example, $hehe variable has two gb2312-encoded chinese chars. This might relate to setlocale or something like that. Reproduce code: --- $hehe = hehe/ºÕºÕ haha kkk; echo basename($hehe).\n; echo substr($hehe, strrpos($hehe, /)+1); Expected result: ºÕºÕ haha kkk ºÕºÕ haha kkk Actual result: -- haha kkk ºÕºÕ haha kkk -- Edit this bug report at http://bugs.php.net/?id=29542edit=1
#29542 [NEW]: basename() has problem in supporting multi-byte chars.
From: ppmm at wuxinan dot net Operating system: Windows 2000 Prof. PHP version: 5.0.0 PHP Bug Type: Filesystem function related Bug description: basename() has problem in supporting multi-byte chars. Description: when path has multi-byte chars, basename() does not return correct file basename. I did not have this problem in PHP 4.3.7. In the example, $hehe variable has two gb2312-encoded chinese chars. This might relate to setlocale or something like that. Reproduce code: --- $hehe = hehe/ºÕºÕ haha kkk; echo basename($hehe).\n; echo substr($hehe, strrpos($hehe, /)+1); Expected result: ºÕºÕ haha kkk ºÕºÕ haha kkk Actual result: -- haha kkk ºÕºÕ haha kkk -- Edit bug report at http://bugs.php.net/?id=29542edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29542r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29542r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29542r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29542r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29542r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29542r=needscript Try newer version: http://bugs.php.net/fix.php?id=29542r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29542r=support Expected behavior: http://bugs.php.net/fix.php?id=29542r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29542r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29542r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29542r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29542r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29542r=dst IIS Stability: http://bugs.php.net/fix.php?id=29542r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29542r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29542r=float
#28753 [WFx]: adding [] to the querystring often produce error
ID: 28753 User updated by: ppmm at wuxinan dot net Reported By: ppmm at wuxinan dot net Status: Wont fix Bug Type: Arrays related Operating System: All PHP Version: 4.3.7 New Comment: true. But might be useful if we can turn off this feature via php.ini Previous Comments: [2004-06-12 12:19:53] [EMAIL PROTECTED] This is up to the programmers, not to us to fix. [2004-06-12 11:52:14] ppmm at wuxinan dot net Description: Have a look at the following URL, for example: http://us2.php.net/source.php?url[]=/manual/en/installation.php I think it's a very classical problem in PHP. $_GET[url] becomes an array in PHP script. This is a good thing, but the side-effect is that when $_GET[url] is not expected to be an array, script would often produce an error, the message of which often includes the filesystem path of the PHP file on the server. Surf whatever PHP-based website and try this trick, it would often produce a great error message for hackers. Sure, webmaster could, however, prevent this kind of error from happening by some simple error checking. However, I mean, in the future release of PHP, is there any way we can do things better? Or somehow we need to educate webmaster about this (possibly security-related) issue. -- Edit this bug report at http://bugs.php.net/?id=28753edit=1
#28753 [NEW]: adding [] to the querystring often produce error
From: ppmm at wuxinan dot net Operating system: All PHP version: 4.3.7 PHP Bug Type: Arrays related Bug description: adding [] to the querystring often produce error Description: Have a look at the following URL, for example: http://us2.php.net/source.php?url[]=/manual/en/installation.php I think it's a very classical problem in PHP. $_GET[url] becomes an array in PHP script. This is a good thing, but the side-effect is that when $_GET[url] is not expected to be an array, script would often produce an error, the message of which often includes the filesystem path of the PHP file on the server. Surf whatever PHP-based website and try this trick, it would often produce a great error message for hackers. Sure, webmaster could, however, prevent this kind of error from happening by some simple error checking. However, I mean, in the future release of PHP, is there any way we can do things better? Or somehow we need to educate webmaster about this (possibly security-related) issue. -- Edit bug report at http://bugs.php.net/?id=28753edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28753r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28753r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28753r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28753r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28753r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28753r=needscript Try newer version: http://bugs.php.net/fix.php?id=28753r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28753r=support Expected behavior: http://bugs.php.net/fix.php?id=28753r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28753r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28753r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28753r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28753r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28753r=dst IIS Stability: http://bugs.php.net/fix.php?id=28753r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28753r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28753r=float
#27758 [Com]: High memory usage/leak
ID: 27758 Comment by: ppmm at wuxinan dot net Reported By: tingle at virtuanews dot co dot uk Status: Open Bug Type: Performance problem Operating System: Windows 2000 SP4 PHP Version: 5CVS-2004-03-29 (dev) New Comment: Try to use Apache 2.0.48. I have exactly the same problem on the same platform. But when I go back to the older version of Apache, the problem no long exists. Previous Comments: [2004-05-03 20:53:00] jpleveille at gameloft dot com I noticed that on the RC2. Is that fixed? I got memory usage increased of 1 to 8 megabytes sometimes. Have to reload Apache every 10 minutes sometimes, annoying! JP. [2004-04-18 10:35:57] tingle at virtuanews dot co dot uk Hi, Sorry for the delay - I was not in a position to download the latest CVS due to a very slow web connection, this has now changed and I have just downloaded the latest file. The problem is now MUCH better, but is still there slightly, where as before it would increase with about 500KB each refresh, it does it by about 50KB each time. It is not as bad, but it is still there [2004-04-12 17:56:11] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2004-04-07 05:25:35] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-03-29 15:05:54] tingle at virtuanews dot co dot uk Description: Hi, Whilst using PHP locally I am experiencing a major problem with memory usage. When I start up apache it uses around 15mb of memory (apache.exe that is) Now as a test I sat hitting refresh on the index page of phpmyadmin installed locally for a few minutes, and the memory usage of apache.exe reached 150mb +. It seems to be using a certain amount of memory to load the page, then not releasing it as the usage never goes down, only up with each page refresh. This issue does NOT happen with PHP4, I am using the latest CVS version of PHP5 compiled by you for windows. I also have apache 2.0.49 and mysql 4.0.18 installed. I realise this is a pretty usless bug report in terms of finding a solution, but that is because I do not know what to give you. Please let me know how I can help to solve this problem - I'm sure needed to restart apahe after every thousand or so page refreses due to memory usage of nearly 200mb is not the intended use of PHP! Thanks Tingle -- Edit this bug report at http://bugs.php.net/?id=27758edit=1
