#50962 [NoF-Opn]: Using a ftp stream to a windows ftp server to upload results in missing data
ID: 50962
User updated by: m dot ebbers at i-real dot nl
Reported By: m dot ebbers at i-real dot nl
-Status: No Feedback
+Status: Open
Bug Type: Streams related
Operating System: Linux
PHP Version: 5.3.1
New Comment:
I've tested it with the given snapshot:
PHP 5.3.3-dev (cli) (built: Feb 23 2010 08:21:46)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
With the same results. Files are not always complete. :(
Previous Comments:
[2010-02-21 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2010-02-13 21:49:40] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-02-08 09:29:16] m dot ebbers at i-real dot nl
Description:
When fopen/fwrite are used to upload a file, through ftp to a ftp
server running on windows, it is not always uploaded completely despite
the fact that fwrite returns that all bytes of the file are written.
I've testen the following scenarios with the attached code:
From Ubuntu 9.10 to Bulletproof ftpd under windows xp (vmware).
(failed)
From Ubuntu 9.10 to Serv-u ftpd under windows xp (vmware). (failed)
From Ubuntu 9.10 to vsftpd on same machine. (ok)
Different hardware and network:
From CentOS release 5 to Bulletproof ftpd on windows server (failed)
When using the ftp command it all works great.
Also tried the build-in ftp client from php and that works fine. It
only failed when using fopen/fwrite/file_put_contents.
Reproduce code:
---
$host = '192.168.1.34';
$user = 'marke';
$passwd = 'ebbers';
$path = '/';
$file = $argv[1];
$url='ftp://'.$user.':'.$passwd.'@'.$host.$path.$file;
$content = file_get_contents($file);
$handle = fopen($url, 'w');
$written = 0;
while ($written != strlen($content))
{
$write = fwrite($handle, substr($content, $written));
fflush($handle);
if($write){
$written .= $write;
echo Written: .$written.'\n';
}else{
break;
}
}
Expected result:
Output script: Written: 293346 (Test file is 293346 bytes.)
And a file on the ftp server of the same size.
Actual result:
--
Output script: Written: 293346 (Test file is 293346 bytes.)
A file on the server, but it is smaller. (and the sizes varies)
I've also a wireshark sniff available. The strange thing in the sniff
is that the every byte of the file is actually send, but by an unknown
reason there is tcp resend and the data in that resend is also the last
data in the file on the server.
Strace:
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
socket(PF_NETLINK, SOCK_RAW, 0) = 3
bind(3, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=6499, groups=}, [12])
= 0
sendto(3, \24\0\0\0\26\0\1\3\220\321oK\0\0\0\0\0\0\0\0, 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=},
msg_iov(1)=[{0\0\0\0\24\0\2\0\220\321oKc\31\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 228
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=},
msg_iov(1)=[{@\0\0\0\24\0\2\0\220\321oKc\31\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 256
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=},
msg_iov(1)=[{\24\0\0\0\3\0\2\0\220\321oKc\31\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 20
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(21),
sin_addr=inet_addr(192.168.1.34)}, 16) = -1 EINPROGRESS (Operation now
in progress)
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
recv(3, 220 Serv-U FTP Server v9.3 ready..., 8192, MSG_DONTWAIT) =
37
send(3, USER marke\r\n, 12, MSG_DONTWAIT) = 12
recv(3, 331 User name okay, need passwor..., 8192, MSG_DONTWAIT) =
36
send(3, PASS ebbers\r\n, 13, MSG_DONTWAIT) = 13
recv(3, 230 User logged in, proceed.\r\n, 8192, MSG_DONTWAIT) = 30
send(3, TYPE I\r\n, 8, MSG_DONTWAIT) = 8
recv(3, 200 Type set to I.\r\n, 8192, MSG_DONTWAIT) = 20
send(3, SIZE /bin2\r\n, 12, MSG_DONTWAIT) = 12
recv(3, 550 /bin2: No such file.\r\n, 8192, MSG_DONTWAIT) = 26
send(3, EPSV\r\n, 6, MSG_DONTWAIT)= 6
recv(3, 500 'EPSV': command not understo..., 8192, MSG_DONTWAIT) =
37
send(3, PASV\r\n, 6, MSG_DONTWAIT)
#51120 [NEW]: If session var is NULL, value will be overwritten by global with same name
From: antonio04 at gmail dot com
Operating system: FreeBSD 7.2
PHP version: 5.3.1
PHP Bug Type: Session related
Bug description: If session var is NULL, value will be overwritten by global
with same name
Description:
When you have a session variable whose whose session array key is
defined but with a NULL value, this variable acts as if register_globals
were enabled, i.e. any value set to a global variable of the same name
is stored in the session as this key's value.
Once the session variable's value has been changed to something not
null, this behavior ceases.
A cursory search in the archives shows that this issue was categorized
as a bogus bug report six years ago (#28482), but the reason given does
not make sense, as the session variable key certainly does exist and
acts unexpectedly when initialized to NULL.
Thanks!
Reproduce code:
---
?php
/* Script 1 */
session_start();
init_set('register_globals', 0);
$_SESSION['foo'] = NULL;
$foo = 'bar';
?
?php
/* Script 2 */
session_start();
var_dump($_SESSION['foo']);
?
Expected result:
Script 1:
Script 2:
Notice: Undefined index: foo in /home/www/interpals/test.php on line 3
NULL
Actual result:
--
Script 1:
Script 2:
string(3) bar
--
Edit bug report at http://bugs.php.net/?id=51120edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51120r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51120r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51120r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51120r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51120r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51120r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51120r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51120r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51120r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51120r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51120r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51120r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51120r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51120r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51120r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51120r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51120r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51120r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51120r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51120r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51120r=mysqlcfg
#51120 [Com]: If session var is NULL, value will be overwritten by global with same name
ID: 51120
Comment by: antonio04 at gmail dot com
Reported By: antonio04 at gmail dot com
Status: Open
Bug Type: Session related
Operating System: FreeBSD 7.2
PHP Version: 5.3.1
New Comment:
Sorry, there was a typo in the reproduce code -- please check this
instead:
?php
/* Script one */
ini_set('register_globals', 0);
session_start();
$_SESSION['foo'] = NULL;
$foo = 'bar';
?
Then view the second script:
?php
/* Script two */
session_start();
var_dump($_SESSION['foo']);
?
Previous Comments:
[2010-02-23 08:30:05] antonio04 at gmail dot com
Description:
When you have a session variable whose whose session array key is
defined but with a NULL value, this variable acts as if
register_globals
were enabled, i.e. any value set to a global variable of the same name
is stored in the session as this key's value.
Once the session variable's value has been changed to something not
null, this behavior ceases.
A cursory search in the archives shows that this issue was categorized
as a bogus bug report six years ago (#28482), but the reason given does
not make sense, as the session variable key certainly does exist and
acts unexpectedly when initialized to NULL.
Thanks!
Reproduce code:
---
?php
/* Script 1 */
session_start();
init_set('register_globals', 0);
$_SESSION['foo'] = NULL;
$foo = 'bar';
?
?php
/* Script 2 */
session_start();
var_dump($_SESSION['foo']);
?
Expected result:
Script 1:
Script 2:
Notice: Undefined index: foo in /home/www/interpals/test.php on line 3
NULL
Actual result:
--
Script 1:
Script 2:
string(3) bar
--
Edit this bug report at http://bugs.php.net/?id=51120edit=1
#51120 [Com]: If session var is NULL, value will be overwritten by global with same name
ID: 51120
Comment by: antonio04 at gmail dot com
Reported By: antonio04 at gmail dot com
Status: Open
Bug Type: Session related
Operating System: FreeBSD 7.2
PHP Version: 5.3.1
New Comment:
Here are the expected/actual results:
Expected result:
Script 1:
Script 2:
NULL
Actual result:
--
Script 1:
Script 2:
string(3) bar
Previous Comments:
[2010-02-23 08:42:13] antonio04 at gmail dot com
Sorry, there was a typo in the reproduce code -- please check this
instead:
?php
/* Script one */
ini_set('register_globals', 0);
session_start();
$_SESSION['foo'] = NULL;
$foo = 'bar';
?
Then view the second script:
?php
/* Script two */
session_start();
var_dump($_SESSION['foo']);
?
[2010-02-23 08:30:05] antonio04 at gmail dot com
Description:
When you have a session variable whose whose session array key is
defined but with a NULL value, this variable acts as if
register_globals
were enabled, i.e. any value set to a global variable of the same name
is stored in the session as this key's value.
Once the session variable's value has been changed to something not
null, this behavior ceases.
A cursory search in the archives shows that this issue was categorized
as a bogus bug report six years ago (#28482), but the reason given does
not make sense, as the session variable key certainly does exist and
acts unexpectedly when initialized to NULL.
Thanks!
Reproduce code:
---
?php
/* Script 1 */
session_start();
init_set('register_globals', 0);
$_SESSION['foo'] = NULL;
$foo = 'bar';
?
?php
/* Script 2 */
session_start();
var_dump($_SESSION['foo']);
?
Expected result:
Script 1:
Script 2:
Notice: Undefined index: foo in /home/www/interpals/test.php on line 3
NULL
Actual result:
--
Script 1:
Script 2:
string(3) bar
--
Edit this bug report at http://bugs.php.net/?id=51120edit=1
#50990 [Opn-Csd]: gmp extension doesn't compile with gmp 5.0.1
ID: 50990 Updated by: paj...@php.net Reported By: php-bugs-2010 at ryandesign dot com -Status: Open +Status: Closed Bug Type: GNU MP related Operating System: Mac OS X 10.6.2 PHP Version: 5.3.2RC1 New Comment: @susan dot smith dot dev at gmail dot com Thing is your emotional replies have simply little to do with the actual issues (the technical one is indeed easy to fix). We have to be careful that no viral (no bad meaning here) licensed code got in or is used with php, to avoid troubles. We have met issues already with the same kind of license changes and we really don't want this mess again. That has nothing to do with propaganda or any other pollitical discussions. PHP is known to have a very liberal license and what we provide usually have no limitation for commercial/closed source/free softwares usage. Now, about the issue, I applied a fix that should work with (very) old versions as well. Previous Comments: [2010-02-19 08:26:58] susan dot smith dot dev at gmail dot com @ pajoye at php dot net I should probably ignore your comment, simply... Was I not polite? Why? Did I say that someone choice are madness? Or I simply said that different libraries give different support to different systems? Users should be free to make their own choice, shouldn't they? Some PHP users asked for a very small compatibility issue, and someone here suggested them to change the library they are using... This is not respect for users choices, is it? I suggested a very simple change. With it, PHP will be compatible with old GMP versions, with the last GMP version, with old MPIR versions and with the last MPIR version. You may say that suggesting such a small change is not polite, maybe... but it solved the problems to the users. Is there someone that is using this ticket for propaganda? Instead of using it for bug-tracking? Read the entire thread and guess who :-) I suggest to close this discussion this way: verify if the suggested change breaks anything, apply it, and close the ticket. Sorry if you feel this last suggestion as not polite. I'll not answer any more, the bug was solved. [2010-02-18 22:52:46] paj...@php.net @susan dot smith dot dev at gmail dot com Please stay pollite. MPIR has more maintainers, more open and active. Yes, GMP is still under development, but that's about it. Now about lgpl v3, we are certainly not on the same line. [2010-02-18 18:11:43] vikingjs at mac dot com Thanks, Susan - that substitution (in gmp.c on line 1362 for those following at home) got me over this hurdle as well. [2010-02-17 15:52:57] susan dot smith dot dev at gmail dot com Don't be silly! MPIR gives better support for Windows, not for modern architecture, on POSIX systems GMP (http://gmplib.org/) is usually better... and LGPL v3 is as compatible with the licence of PHP as LGPL v2 is. I solved replacing the outdated __GMP_BITS_PER_MP_LIMB defined constant with GMP_LIMB_BITS. The latter is present in all previous versions, and MPIR define it too. [2010-02-10 10:56:33] paj...@php.net ZF depends on the gmp php extension, which can be built against MPIR instead of gmplib. See http://www.mpir.org/. It is a rock solid gmp compatible library with much better support for modern architecture and optimizations, without the (l)gpl v3 license madness. 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/50990 -- Edit this bug report at http://bugs.php.net/?id=50990edit=1
#51122 [NEW]: the iteration on arrays with calling functions is very slow
From: y_kopel at walla dot com
Operating system: linux
PHP version: 5.3.1
PHP Bug Type: Arrays related
Bug description: the iteration on arrays with calling functions is very slow
Description:
the iteration on arrays with calling functions is very slow
comparing php 5.2.1 to 5.3.1
Reproduce code:
---
?php
define(FLOATING_POINT,6);
function ww($f){
echo sprintf(%..FLOATING_POINT.f, $f).\n;
}
class A{
protected $users;
function __construct(){
for ($i = 0 ;$i 10 ; $i++){
$this-users[$i]['ELEMENT'] = array(a,b);
$this-users[$i]['SUM'] = 2;
}
}
function check_more_than_one_element(){
$sum = 0;
foreach ($this-users as $u){
if (count($u['ELEMENT']) 1){
$sum++;
}
}
return $sum;
}
function a_check_more_than_one_element(){
$sum = 0;
foreach ($this-users as $u){
if ($u['SUM'] 1){
$sum++;
}
}
return $sum;
}
}
$a = new A();
$start = microtime(true);
echo -\n;
for ($i = 0 ;$i 5 ; $i++){
$a-check_more_than_one_element();
$a-check_more_than_one_element();
$a-check_more_than_one_element();
$a-check_more_than_one_element();
}
echo -\n;
echo microtime(true) - $start.\n;
$a = new A();
$start = microtime(true);
echo -\n;
for ($i = 0 ;$i 5 ; $i++){
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
}
echo -\n;
echo microtime(true) - $start.\n;
?
Expected result:
php 5.2.1
=
-
-
1.75261092186
-
-
1.05390191078
Actual result:
--
php 5.3.1
=
-
-
58.992564916611
-
-
30.829360961914
--
Edit bug report at http://bugs.php.net/?id=51122edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51122r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51122r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51122r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51122r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51122r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51122r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51122r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51122r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51122r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51122r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51122r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51122r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51122r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51122r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51122r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51122r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51122r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51122r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51122r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51122r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51122r=mysqlcfg
#51122 [Opn]: the iteration on arrays with calling functions is very slow
ID: 51122
User updated by: y_kopel at walla dot com
Reported By: y_kopel at walla dot com
Status: Open
Bug Type: Arrays related
Operating System: linux
PHP Version: 5.3.1
New Comment:
shorter code:
?php
for ($i = 0 ;$i 100 ; $i++){
$users[$i]['SUM'] = 2;
}
$start = microtime(true);
$sum = 0;
foreach ($users as $u){
if ($u['SUM'] 1){ $sum++;}
}
echo microtime(true) - $start.\n;
?
OUTPUT
==
php 5.2.1
=
0.328261852264
php 5.3.1
=
42.350708961487
Previous Comments:
[2010-02-23 11:40:36] y_kopel at walla dot com
Description:
the iteration on arrays with calling functions is very slow
comparing php 5.2.1 to 5.3.1
Reproduce code:
---
?php
define(FLOATING_POINT,6);
function ww($f){
echo sprintf(%..FLOATING_POINT.f, $f).\n;
}
class A{
protected $users;
function __construct(){
for ($i = 0 ;$i 10 ; $i++){
$this-users[$i]['ELEMENT'] = array(a,b);
$this-users[$i]['SUM'] = 2;
}
}
function check_more_than_one_element(){
$sum = 0;
foreach ($this-users as $u){
if (count($u['ELEMENT']) 1){
$sum++;
}
}
return $sum;
}
function a_check_more_than_one_element(){
$sum = 0;
foreach ($this-users as $u){
if ($u['SUM'] 1){
$sum++;
}
}
return $sum;
}
}
$a = new A();
$start = microtime(true);
echo -\n;
for ($i = 0 ;$i 5 ; $i++){
$a-check_more_than_one_element();
$a-check_more_than_one_element();
$a-check_more_than_one_element();
$a-check_more_than_one_element();
}
echo -\n;
echo microtime(true) - $start.\n;
$a = new A();
$start = microtime(true);
echo -\n;
for ($i = 0 ;$i 5 ; $i++){
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
}
echo -\n;
echo microtime(true) - $start.\n;
?
Expected result:
php 5.2.1
=
-
-
1.75261092186
-
-
1.05390191078
Actual result:
--
php 5.3.1
=
-
-
58.992564916611
-
-
30.829360961914
--
Edit this bug report at http://bugs.php.net/?id=51122edit=1
#51123 [NEW]: Mail function error can't to connect mail server.
From: som_sea at hotmail dot com Operating system: Windows XP PHP version: 5.2.12 PHP Bug Type: Mail related Bug description: Mail function error can't to connect mail server. Description: Background version. AppServ Open Project - 2.5.8 for Windows : Apache Web Server Version 2.2.4 PHP Script Language Version 5.2.1 MySQL Database Version 5.0.27 phpMyAdmin Database Manager Version 2.9.2 Problem:Can not connect to mail sever. Error msg. Warning: mail() [function.mail]: Failed to connect to mailserver at XX port 25, verify your SMTP and smtp_port setting in php.ini or use ini_set() in C:\AppServ\www\xxx.php on line xx = If use this script/mailserver/ini-mail-set with php ver.4.xx(Appserv v.2.4) its work. How can do??? Actual result: -- Warning: mail() [function.mail]: Failed to connect to mailserver at XX port 25, verify your SMTP and smtp_port setting in php.ini or use ini_set() in C:\AppServ\www\xxx.php on line xx -- Edit bug report at http://bugs.php.net/?id=51123edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51123r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51123r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51123r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51123r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51123r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51123r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51123r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51123r=needscript Try newer version: http://bugs.php.net/fix.php?id=51123r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51123r=support Expected behavior: http://bugs.php.net/fix.php?id=51123r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51123r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51123r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51123r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51123r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51123r=dst IIS Stability: http://bugs.php.net/fix.php?id=51123r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51123r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51123r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51123r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51123r=mysqlcfg
#51120 [Opn-Bgs]: If session var is NULL, value will be overwritten by global with same name
ID: 51120
Updated by: j...@php.net
Reported By: antonio04 at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: FreeBSD 7.2
PHP Version: 5.3.1
New Comment:
For starters, you can't set register_globals in script. Hence there's
no bug but expected (bad) behaviour on having register_globals = On.
Switch it off and all is well. :)
Previous Comments:
[2010-02-23 10:33:50] antonio04 at gmail dot com
Here are the expected/actual results:
Expected result:
Script 1:
Script 2:
NULL
Actual result:
--
Script 1:
Script 2:
string(3) bar
[2010-02-23 08:42:13] antonio04 at gmail dot com
Sorry, there was a typo in the reproduce code -- please check this
instead:
?php
/* Script one */
ini_set('register_globals', 0);
session_start();
$_SESSION['foo'] = NULL;
$foo = 'bar';
?
Then view the second script:
?php
/* Script two */
session_start();
var_dump($_SESSION['foo']);
?
[2010-02-23 08:30:05] antonio04 at gmail dot com
Description:
When you have a session variable whose whose session array key is
defined but with a NULL value, this variable acts as if
register_globals
were enabled, i.e. any value set to a global variable of the same name
is stored in the session as this key's value.
Once the session variable's value has been changed to something not
null, this behavior ceases.
A cursory search in the archives shows that this issue was categorized
as a bogus bug report six years ago (#28482), but the reason given does
not make sense, as the session variable key certainly does exist and
acts unexpectedly when initialized to NULL.
Thanks!
Reproduce code:
---
?php
/* Script 1 */
session_start();
init_set('register_globals', 0);
$_SESSION['foo'] = NULL;
$foo = 'bar';
?
?php
/* Script 2 */
session_start();
var_dump($_SESSION['foo']);
?
Expected result:
Script 1:
Script 2:
Notice: Undefined index: foo in /home/www/interpals/test.php on line 3
NULL
Actual result:
--
Script 1:
Script 2:
string(3) bar
--
Edit this bug report at http://bugs.php.net/?id=51120edit=1
#51122 [Opn-Bgs]: the iteration on arrays with calling functions is very slow
ID: 51122
Updated by: j...@php.net
Reported By: y_kopel at walla dot com
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: linux
PHP Version: 5.3.1
New Comment:
Just turn off garbage collection if this is a problem for you.
(zend.enable_gc = off in php.ini)
Previous Comments:
[2010-02-23 11:54:00] y_kopel at walla dot com
shorter code:
?php
for ($i = 0 ;$i 100 ; $i++){
$users[$i]['SUM'] = 2;
}
$start = microtime(true);
$sum = 0;
foreach ($users as $u){
if ($u['SUM'] 1){ $sum++;}
}
echo microtime(true) - $start.\n;
?
OUTPUT
==
php 5.2.1
=
0.328261852264
php 5.3.1
=
42.350708961487
[2010-02-23 11:40:36] y_kopel at walla dot com
Description:
the iteration on arrays with calling functions is very slow
comparing php 5.2.1 to 5.3.1
Reproduce code:
---
?php
define(FLOATING_POINT,6);
function ww($f){
echo sprintf(%..FLOATING_POINT.f, $f).\n;
}
class A{
protected $users;
function __construct(){
for ($i = 0 ;$i 10 ; $i++){
$this-users[$i]['ELEMENT'] = array(a,b);
$this-users[$i]['SUM'] = 2;
}
}
function check_more_than_one_element(){
$sum = 0;
foreach ($this-users as $u){
if (count($u['ELEMENT']) 1){
$sum++;
}
}
return $sum;
}
function a_check_more_than_one_element(){
$sum = 0;
foreach ($this-users as $u){
if ($u['SUM'] 1){
$sum++;
}
}
return $sum;
}
}
$a = new A();
$start = microtime(true);
echo -\n;
for ($i = 0 ;$i 5 ; $i++){
$a-check_more_than_one_element();
$a-check_more_than_one_element();
$a-check_more_than_one_element();
$a-check_more_than_one_element();
}
echo -\n;
echo microtime(true) - $start.\n;
$a = new A();
$start = microtime(true);
echo -\n;
for ($i = 0 ;$i 5 ; $i++){
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
}
echo -\n;
echo microtime(true) - $start.\n;
?
Expected result:
php 5.2.1
=
-
-
1.75261092186
-
-
1.05390191078
Actual result:
--
php 5.3.1
=
-
-
58.992564916611
-
-
30.829360961914
--
Edit this bug report at http://bugs.php.net/?id=51122edit=1
#51122 [Bgs]: the iteration on arrays with calling functions is very slow
ID: 51122
Updated by: j...@php.net
Reported By: y_kopel at walla dot com
Status: Bogus
Bug Type: Arrays related
Operating System: linux
PHP Version: 5.3.1
New Comment:
Or run the script in 32bit system (and turn of GC :).
With latest SVN checkout of PHP_5_3:
$ src/build/php_5_3/sapi/cli/php -dmemory_limit=1G t.php
1.2259361743927
$ src/build/php_5_3/sapi/cli/php -dmemory_limit=1G -dzend.enable_gc=0
t.php
0.70840787887573
And with latest SVN checkout of PHP_5_2:
$ src/build/php_5_2/sapi/cli/php -dmemory_limit=1G t.php
0.69131684303284
Not noticeable even.
Previous Comments:
[2010-02-23 12:59:02] j...@php.net
Just turn off garbage collection if this is a problem for you.
(zend.enable_gc = off in php.ini)
[2010-02-23 11:54:00] y_kopel at walla dot com
shorter code:
?php
for ($i = 0 ;$i 100 ; $i++){
$users[$i]['SUM'] = 2;
}
$start = microtime(true);
$sum = 0;
foreach ($users as $u){
if ($u['SUM'] 1){ $sum++;}
}
echo microtime(true) - $start.\n;
?
OUTPUT
==
php 5.2.1
=
0.328261852264
php 5.3.1
=
42.350708961487
[2010-02-23 11:40:36] y_kopel at walla dot com
Description:
the iteration on arrays with calling functions is very slow
comparing php 5.2.1 to 5.3.1
Reproduce code:
---
?php
define(FLOATING_POINT,6);
function ww($f){
echo sprintf(%..FLOATING_POINT.f, $f).\n;
}
class A{
protected $users;
function __construct(){
for ($i = 0 ;$i 10 ; $i++){
$this-users[$i]['ELEMENT'] = array(a,b);
$this-users[$i]['SUM'] = 2;
}
}
function check_more_than_one_element(){
$sum = 0;
foreach ($this-users as $u){
if (count($u['ELEMENT']) 1){
$sum++;
}
}
return $sum;
}
function a_check_more_than_one_element(){
$sum = 0;
foreach ($this-users as $u){
if ($u['SUM'] 1){
$sum++;
}
}
return $sum;
}
}
$a = new A();
$start = microtime(true);
echo -\n;
for ($i = 0 ;$i 5 ; $i++){
$a-check_more_than_one_element();
$a-check_more_than_one_element();
$a-check_more_than_one_element();
$a-check_more_than_one_element();
}
echo -\n;
echo microtime(true) - $start.\n;
$a = new A();
$start = microtime(true);
echo -\n;
for ($i = 0 ;$i 5 ; $i++){
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
}
echo -\n;
echo microtime(true) - $start.\n;
?
Expected result:
php 5.2.1
=
-
-
1.75261092186
-
-
1.05390191078
Actual result:
--
php 5.3.1
=
-
-
58.992564916611
-
-
30.829360961914
--
Edit this bug report at http://bugs.php.net/?id=51122edit=1
#51123 [Opn-Bgs]: Mail function error can't to connect mail server.
ID: 51123 Updated by: j...@php.net Reported By: som_sea at hotmail dot com -Status: Open +Status: Bogus Bug Type: Mail related Operating System: Windows XP PHP Version: 5.2.12 New Comment: 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. Previous Comments: [2010-02-23 12:46:54] som_sea at hotmail dot com Description: Background version. AppServ Open Project - 2.5.8 for Windows : Apache Web Server Version 2.2.4 PHP Script Language Version 5.2.1 MySQL Database Version 5.0.27 phpMyAdmin Database Manager Version 2.9.2 Problem:Can not connect to mail sever. Error msg. Warning: mail() [function.mail]: Failed to connect to mailserver at XX port 25, verify your SMTP and smtp_port setting in php.ini or use ini_set() in C:\AppServ\www\xxx.php on line xx = If use this script/mailserver/ini-mail-set with php ver.4.xx(Appserv v.2.4) its work. How can do??? Actual result: -- Warning: mail() [function.mail]: Failed to connect to mailserver at XX port 25, verify your SMTP and smtp_port setting in php.ini or use ini_set() in C:\AppServ\www\xxx.php on line xx -- Edit this bug report at http://bugs.php.net/?id=51123edit=1
#51023 [Opn]: ext/filter/tests/046.phpt fails, does not detect int overflow (with -O2 gcc 4.4)
ID: 51023 Updated by: j...@php.net Reported By: geissert at debian dot org Status: Open Bug Type: Filter related Operating System: * PHP Version: 5.3SVN-2010-02-12 New Comment: See also bug #51008 Previous Comments: [2010-02-20 20:56:44] geiss...@php.net Further investigation revealed that the bug occurs with gcc 4.4 and optimisation -02. Without optimisation the code still works. [2010-02-11 23:31:02] geissert at debian dot org Description: The filter fails to detect an integer overflow and passes the FILTER_VALIDATE_INT test. The problem is caused because php_filter_parse_int uses a long to detect the overflow, which of course doesn't have the same size of an integer. This can be fixed by making ctx_value an integer in both php_filter_parse_int and php_filter_int (and for correctness, not setting Z_TYPE_P(value) to IS_LONG). Reproduce code: --- // the current test: $s = sprintf(%d, PHP_INT_MAX); var_dump(is_long(filter_var($s, FILTER_VALIDATE_INT))); $s = sprintf(%.0f, PHP_INT_MAX+1); var_dump(filter_var($s, FILTER_VALIDATE_INT)); $s = sprintf(%d, -PHP_INT_MAX); var_dump(is_long(filter_var($s, FILTER_VALIDATE_INT))); Expected result: bool(true) bool(false) bool(true) Actual result: -- bool(true) int(-2147483648) bool(true) -- Edit this bug report at http://bugs.php.net/?id=51023edit=1
#51008 [Opn-Bgs]: Zend/tests/bug45877.phpt fails
ID: 51008
Updated by: j...@php.net
Reported By: geissert at debian dot org
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: debian sid
PHP Version: 5.3SVN-2010-02-12
New Comment:
Duplicate.
Previous Comments:
[2010-02-22 23:47:30] geiss...@php.net
Indeed. I just checked with the -O0 build and it passes.
The affected code in this case is ZEND_HANDLE_NUMERIC in
Zend/zend_hash.h
Should this one be assigned to somebody in particular?
[2010-02-22 18:05:08] sni...@php.net
Possibly same issue as bug #51023 ??
[2010-02-12 18:58:42] geissert at debian dot org
It fails for me with 5.3.1 on i686, ia64, s390, alpha, powerpc, x86_64,
etc. Even on those running kfreebsd.
It also fails with the latest 5.3 svn on ia64 (haven't built it on any
other arch.)
[2010-02-12 17:02:47] j...@php.net
In what kind of environment does it fail? It works fine for me in both
32bit and 64bit systems. (using latest SVN checkout of course :)
[2010-02-11 01:54:21] geissert at debian dot org
Description:
The test fails
Reproduce code:
---
?php
$keys = array(PHP_INT_MAX,
(string) PHP_INT_MAX,
(string) (-PHP_INT_MAX - 1),
-PHP_INT_MAX - 1,
(string) (PHP_INT_MAX + 1));
var_dump(array_fill_keys($keys, 1));
?
Expected result:
array(2) {
[2147483647]=
int(1)
[-2147483648]=
int(1)
[2147483648]=
int(1)
}
Actual result:
--
array(2) {
[2147483647]=
int(1)
[-2147483648]=
int(1)
}
--
Edit this bug report at http://bugs.php.net/?id=51008edit=1
#51120 [Bgs]: If session var is NULL, value will be overwritten by global with same name
ID: 51120
User updated by: antonio04 at gmail dot com
Reported By: antonio04 at gmail dot com
Status: Bogus
Bug Type: Session related
Operating System: FreeBSD 7.2
PHP Version: 5.3.1
New Comment:
Thanks for your quick response.
Sorry, I should have mentioned that register_globals is off in php.ini.
I included the ini_set line to illustrate that point, but I suppose
that's moot, since you can't set it via ini_set =)
However, the problem is still there... can you please try to reproduce
it?
Previous Comments:
[2010-02-23 12:55:53] j...@php.net
For starters, you can't set register_globals in script. Hence there's
no bug but expected (bad) behaviour on having register_globals = On.
Switch it off and all is well. :)
[2010-02-23 10:33:50] antonio04 at gmail dot com
Here are the expected/actual results:
Expected result:
Script 1:
Script 2:
NULL
Actual result:
--
Script 1:
Script 2:
string(3) bar
[2010-02-23 08:42:13] antonio04 at gmail dot com
Sorry, there was a typo in the reproduce code -- please check this
instead:
?php
/* Script one */
ini_set('register_globals', 0);
session_start();
$_SESSION['foo'] = NULL;
$foo = 'bar';
?
Then view the second script:
?php
/* Script two */
session_start();
var_dump($_SESSION['foo']);
?
[2010-02-23 08:30:05] antonio04 at gmail dot com
Description:
When you have a session variable whose whose session array key is
defined but with a NULL value, this variable acts as if
register_globals
were enabled, i.e. any value set to a global variable of the same name
is stored in the session as this key's value.
Once the session variable's value has been changed to something not
null, this behavior ceases.
A cursory search in the archives shows that this issue was categorized
as a bogus bug report six years ago (#28482), but the reason given does
not make sense, as the session variable key certainly does exist and
acts unexpectedly when initialized to NULL.
Thanks!
Reproduce code:
---
?php
/* Script 1 */
session_start();
init_set('register_globals', 0);
$_SESSION['foo'] = NULL;
$foo = 'bar';
?
?php
/* Script 2 */
session_start();
var_dump($_SESSION['foo']);
?
Expected result:
Script 1:
Script 2:
Notice: Undefined index: foo in /home/www/interpals/test.php on line 3
NULL
Actual result:
--
Script 1:
Script 2:
string(3) bar
--
Edit this bug report at http://bugs.php.net/?id=51120edit=1
#50962 [Opn-Fbk]: Using a ftp stream to a windows ftp server to upload results in missing data
ID: 50962
Updated by: j...@php.net
Reported By: m dot ebbers at i-real dot nl
-Status: Open
+Status: Feedback
Bug Type: Streams related
Operating System: Linux
-PHP Version: 5.3.1
+PHP Version: 5.*, 6 (2010-02-23)
New Comment:
When you give feedback, use the correct tab (NOT the Add Comment
one!). And does this happen with any ftp server not under Windows? Any
firewalls or such between? Have you tried the PHP FTP extension instead?
(See more at: http://php.net/ftp )
Previous Comments:
[2010-02-23 08:10:24] m dot ebbers at i-real dot nl
I've tested it with the given snapshot:
PHP 5.3.3-dev (cli) (built: Feb 23 2010 08:21:46)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
With the same results. Files are not always complete. :(
[2010-02-13 21:49:40] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-02-08 09:29:16] m dot ebbers at i-real dot nl
Description:
When fopen/fwrite are used to upload a file, through ftp to a ftp
server running on windows, it is not always uploaded completely despite
the fact that fwrite returns that all bytes of the file are written.
I've testen the following scenarios with the attached code:
From Ubuntu 9.10 to Bulletproof ftpd under windows xp (vmware).
(failed)
From Ubuntu 9.10 to Serv-u ftpd under windows xp (vmware). (failed)
From Ubuntu 9.10 to vsftpd on same machine. (ok)
Different hardware and network:
From CentOS release 5 to Bulletproof ftpd on windows server (failed)
When using the ftp command it all works great.
Also tried the build-in ftp client from php and that works fine. It
only failed when using fopen/fwrite/file_put_contents.
Reproduce code:
---
$host = '192.168.1.34';
$user = 'marke';
$passwd = 'ebbers';
$path = '/';
$file = $argv[1];
$url='ftp://'.$user.':'.$passwd.'@'.$host.$path.$file;
$content = file_get_contents($file);
$handle = fopen($url, 'w');
$written = 0;
while ($written != strlen($content))
{
$write = fwrite($handle, substr($content, $written));
fflush($handle);
if($write){
$written .= $write;
echo Written: .$written.'\n';
}else{
break;
}
}
Expected result:
Output script: Written: 293346 (Test file is 293346 bytes.)
And a file on the ftp server of the same size.
Actual result:
--
Output script: Written: 293346 (Test file is 293346 bytes.)
A file on the server, but it is smaller. (and the sizes varies)
I've also a wireshark sniff available. The strange thing in the sniff
is that the every byte of the file is actually send, but by an unknown
reason there is tcp resend and the data in that resend is also the last
data in the file on the server.
Strace:
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
socket(PF_NETLINK, SOCK_RAW, 0) = 3
bind(3, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=6499, groups=}, [12])
= 0
sendto(3, \24\0\0\0\26\0\1\3\220\321oK\0\0\0\0\0\0\0\0, 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=},
msg_iov(1)=[{0\0\0\0\24\0\2\0\220\321oKc\31\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 228
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=},
msg_iov(1)=[{@\0\0\0\24\0\2\0\220\321oKc\31\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 256
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=},
msg_iov(1)=[{\24\0\0\0\3\0\2\0\220\321oKc\31\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 20
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(21),
sin_addr=inet_addr(192.168.1.34)}, 16) = -1 EINPROGRESS (Operation now
in progress)
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
recv(3, 220 Serv-U FTP Server v9.3 ready..., 8192, MSG_DONTWAIT) =
37
send(3, USER marke\r\n, 12, MSG_DONTWAIT) = 12
recv(3, 331 User name okay, need passwor..., 8192, MSG_DONTWAIT) =
36
send(3, PASS ebbers\r\n, 13, MSG_DONTWAIT) = 13
recv(3, 230 User logged in, proceed.\r\n, 8192, MSG_DONTWAIT) = 30
send(3, TYPE I\r\n, 8, MSG_DONTWAIT) = 8
recv(3, 200 Type set to I.\r\n, 8192, MSG_DONTWAIT) = 20
send(3, SIZE /bin2\r\n, 12, MSG_DONTWAIT) = 12
recv(3, 550 /bin2: No such file.\r\n, 8192, MSG_DONTWAIT) = 26
send(3, EPSV\r\n, 6, MSG_DONTWAIT)= 6
recv(3, 500 'EPSV': command not understo..., 8192, MSG_DONTWAIT) =
37
#51120 [Bgs]: If session var is NULL, value will be overwritten by global with same name
ID: 51120
User updated by: antonio04 at gmail dot com
Reported By: antonio04 at gmail dot com
Status: Bogus
Bug Type: Session related
Operating System: FreeBSD 7.2
PHP Version: 5.3.1
New Comment:
Just to confirm, register_globals is definitely off -- both as reported
by phpinfo() as well as the following snippet:
?php
echo 'register_globals = ' . ini_get('register_globals') . \n;
?
Which displays the following:
register_globals =
Previous Comments:
[2010-02-23 13:07:21] antonio04 at gmail dot com
Thanks for your quick response.
Sorry, I should have mentioned that register_globals is off in php.ini.
I included the ini_set line to illustrate that point, but I suppose
that's moot, since you can't set it via ini_set =)
However, the problem is still there... can you please try to reproduce
it?
[2010-02-23 12:55:53] j...@php.net
For starters, you can't set register_globals in script. Hence there's
no bug but expected (bad) behaviour on having register_globals = On.
Switch it off and all is well. :)
[2010-02-23 10:33:50] antonio04 at gmail dot com
Here are the expected/actual results:
Expected result:
Script 1:
Script 2:
NULL
Actual result:
--
Script 1:
Script 2:
string(3) bar
[2010-02-23 08:42:13] antonio04 at gmail dot com
Sorry, there was a typo in the reproduce code -- please check this
instead:
?php
/* Script one */
ini_set('register_globals', 0);
session_start();
$_SESSION['foo'] = NULL;
$foo = 'bar';
?
Then view the second script:
?php
/* Script two */
session_start();
var_dump($_SESSION['foo']);
?
[2010-02-23 08:30:05] antonio04 at gmail dot com
Description:
When you have a session variable whose whose session array key is
defined but with a NULL value, this variable acts as if
register_globals
were enabled, i.e. any value set to a global variable of the same name
is stored in the session as this key's value.
Once the session variable's value has been changed to something not
null, this behavior ceases.
A cursory search in the archives shows that this issue was categorized
as a bogus bug report six years ago (#28482), but the reason given does
not make sense, as the session variable key certainly does exist and
acts unexpectedly when initialized to NULL.
Thanks!
Reproduce code:
---
?php
/* Script 1 */
session_start();
init_set('register_globals', 0);
$_SESSION['foo'] = NULL;
$foo = 'bar';
?
?php
/* Script 2 */
session_start();
var_dump($_SESSION['foo']);
?
Expected result:
Script 1:
Script 2:
Notice: Undefined index: foo in /home/www/interpals/test.php on line 3
NULL
Actual result:
--
Script 1:
Script 2:
string(3) bar
--
Edit this bug report at http://bugs.php.net/?id=51120edit=1
#51124 [NEW]: if we divide 1.48/15000 answer suppose to be 0.0000986666 but wrong ans coming
From: davindergsi at yahoo dot com Operating system: Linux PHP version: 6SVN-2010-02-23 (snap) PHP Bug Type: Math related Bug description: if we divide 1.48/15000 answer suppose to be 0.98 but wrong ans coming Description: if we divide 1.48/15000 answer is suppose to be 0.98 but wrong ans coming Reproduce code: --- 1.48/15000 Expected result: 0.986 Actual result: -- 9.86667E-5 -- Edit bug report at http://bugs.php.net/?id=51124edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51124r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51124r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51124r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51124r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51124r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51124r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51124r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51124r=needscript Try newer version: http://bugs.php.net/fix.php?id=51124r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51124r=support Expected behavior: http://bugs.php.net/fix.php?id=51124r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51124r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51124r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51124r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51124r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51124r=dst IIS Stability: http://bugs.php.net/fix.php?id=51124r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51124r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51124r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51124r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51124r=mysqlcfg
#51124 [Opn-Bgs]: if we divide 1.48/15000 answer suppose to be 0.0000986666 but wrong ans coming
ID: 51124 Updated by: paj...@php.net Reported By: davindergsi at yahoo dot com -Status: Open +Status: Bogus Bug Type: Math related Operating System: Linux PHP Version: 6SVN-2010-02-23 (snap) New Comment: . Previous Comments: [2010-02-23 13:15:50] davindergsi at yahoo dot com Description: if we divide 1.48/15000 answer is suppose to be 0.98 but wrong ans coming Reproduce code: --- 1.48/15000 Expected result: 0.986 Actual result: -- 9.86667E-5 -- Edit this bug report at http://bugs.php.net/?id=51124edit=1
#48853 [Com]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853
Comment by: leonard-php-bugs at ottolander dot nl
Reported By: leonard-php-bugs at ottolander dot nl
Status: No Feedback
Bug Type: Compile Failure
Operating System: CentOS-4
PHP Version: 5.2CVS-2009-07-08 (CVS)
New Comment:
I am unsure why this report was labeled No Feedback as I provided the
requested configure line within 2 hours after the request was made. I
was not aware of this state change as I haven't received an email
indicting this.
Doing a quick checkup in SVN it seems this issue was not fixed. In
5.3.2 the block where $PHP_PCRE_REGEX = yes tests true got moved to
the bottom of the file, but the required include path still seems not to
be provided.
To shortly restate the issue:
On a system where no other pcre headers are available the headers of
the bundled pcre are not found due to a missing include path and the
build fails.
Since on most systems pcre headers will be available you will need to
explicitly remove the pcre headers provided by the build system
(pcre-devel package or similar) to reproduce this issue. If any other
pcre headers than the bundled ones are available on the system the build
will use those and succeed where it shouldn't.
Build still fails on CentOS(/RHEL)-4 for php-5.2.12. Old headers have
been removed using rpm -e --nodeps pcre-devel. I am aware this is an
unusual situation, but what is the point of building against the bundled
pcre source when the build uses the (old and wrong) headers provided by
the build system? PHP should find and use the headers of the bundled
pcre when building against these, not some random headers available on
the system.
Previous Comments:
[2009-07-16 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2009-07-08 22:29:16] leonard-php-bugs at ottolander dot nl
As I said, I'm not using a --with- or --without-pcre option. The other
options seem not very relevant in this context but I'll paste the line
from the used rpm spec file here. %configure translates to configure ;)
%configure \
--cache-file=../config.cache \
--with-libdir=%{_lib} \
--with-config-file-path=%{_sysconfdir} \
--with-config-file-scan-dir=%{_sysconfdir}/php.d \
--disable-debug \
--with-pic \
--disable-rpath \
--without-pear \
--with-bz2 \
--with-exec-dir=%{_bindir} \
--with-freetype-dir=%{_prefix} \
--with-png-dir=%{_prefix} \
--enable-gd-native-ttf \
--without-gdbm \
--with-gettext \
--with-gmp \
--with-iconv \
--with-jpeg-dir=%{_prefix} \
--with-openssl \
--with-zlib \
--with-layout=GNU \
--enable-exif \
--enable-ftp \
--enable-magic-quotes \
--enable-sockets \
--enable-sysvsem --enable-sysvshm --enable-sysvmsg \
--with-kerberos \
--enable-ucd-snmp-hack \
--enable-shmop \
--enable-calendar \
--without-mime-magic \
--without-sqlite \
--with-libxml-dir=%{_prefix} \
--enable-xml \
--with-system-tzdata \
$*
I'd say, just open ext/pcre/config0.m4 and see there's no
PHP_ADD_INCLUDE inside the second (nested) if that causes httpd.h to be
unable to locate pcreposix.h if no pcre headers are installed on the
system.
If there is already a local copy of the pcre headers installed the
-I/usr/include will cause the build to still find a (possible incorrect)
version of the headers, and it succeeds (if the versions are close
enough).
On my system these headers aren't available as on CentOS-4 they are
version 4.5, so I removed them. This is an unusual situation, which is
probably why nobody noticed this issue before (the local headers are
probably available on most systems because builds like apache depend on
them).
[2009-07-08 20:37:17] j...@php.net
And your configure line is..?
[2009-07-08 14:17:45] leonard-php-bugs at ottolander dot nl
Description:
Building 5.2.9 on CentOS-4, although later versions until CVS today are
affected. The OS is not really relevant, just the reason there are no
unbundled headers available as there's a version mismatch with the
bundled headers.
Using the bundled pcre library by not supplying any pcre configure
options. When the unbundled (upgraded/matching) headers are available on
the system the build succeeds. However, if no unbundled headers are
available httpd.h cannot find
#48853 [NoF-Opn]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853
Updated by: paj...@php.net
Reported By: leonard-php-bugs at ottolander dot nl
-Status: No Feedback
+Status: Open
Bug Type: Compile Failure
Operating System: CentOS-4
PHP Version: 5.2CVS-2009-07-08 (CVS)
Previous Comments:
[2010-02-23 14:18:28] leonard-php-bugs at ottolander dot nl
I am unsure why this report was labeled No Feedback as I provided the
requested configure line within 2 hours after the request was made. I
was not aware of this state change as I haven't received an email
indicting this.
Doing a quick checkup in SVN it seems this issue was not fixed. In
5.3.2 the block where $PHP_PCRE_REGEX = yes tests true got moved to
the bottom of the file, but the required include path still seems not to
be provided.
To shortly restate the issue:
On a system where no other pcre headers are available the headers of
the bundled pcre are not found due to a missing include path and the
build fails.
Since on most systems pcre headers will be available you will need to
explicitly remove the pcre headers provided by the build system
(pcre-devel package or similar) to reproduce this issue. If any other
pcre headers than the bundled ones are available on the system the build
will use those and succeed where it shouldn't.
Build still fails on CentOS(/RHEL)-4 for php-5.2.12. Old headers have
been removed using rpm -e --nodeps pcre-devel. I am aware this is an
unusual situation, but what is the point of building against the bundled
pcre source when the build uses the (old and wrong) headers provided by
the build system? PHP should find and use the headers of the bundled
pcre when building against these, not some random headers available on
the system.
[2009-07-16 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2009-07-08 22:29:16] leonard-php-bugs at ottolander dot nl
As I said, I'm not using a --with- or --without-pcre option. The other
options seem not very relevant in this context but I'll paste the line
from the used rpm spec file here. %configure translates to configure ;)
%configure \
--cache-file=../config.cache \
--with-libdir=%{_lib} \
--with-config-file-path=%{_sysconfdir} \
--with-config-file-scan-dir=%{_sysconfdir}/php.d \
--disable-debug \
--with-pic \
--disable-rpath \
--without-pear \
--with-bz2 \
--with-exec-dir=%{_bindir} \
--with-freetype-dir=%{_prefix} \
--with-png-dir=%{_prefix} \
--enable-gd-native-ttf \
--without-gdbm \
--with-gettext \
--with-gmp \
--with-iconv \
--with-jpeg-dir=%{_prefix} \
--with-openssl \
--with-zlib \
--with-layout=GNU \
--enable-exif \
--enable-ftp \
--enable-magic-quotes \
--enable-sockets \
--enable-sysvsem --enable-sysvshm --enable-sysvmsg \
--with-kerberos \
--enable-ucd-snmp-hack \
--enable-shmop \
--enable-calendar \
--without-mime-magic \
--without-sqlite \
--with-libxml-dir=%{_prefix} \
--enable-xml \
--with-system-tzdata \
$*
I'd say, just open ext/pcre/config0.m4 and see there's no
PHP_ADD_INCLUDE inside the second (nested) if that causes httpd.h to be
unable to locate pcreposix.h if no pcre headers are installed on the
system.
If there is already a local copy of the pcre headers installed the
-I/usr/include will cause the build to still find a (possible incorrect)
version of the headers, and it succeeds (if the versions are close
enough).
On my system these headers aren't available as on CentOS-4 they are
version 4.5, so I removed them. This is an unusual situation, which is
probably why nobody noticed this issue before (the local headers are
probably available on most systems because builds like apache depend on
them).
[2009-07-08 20:37:17] j...@php.net
And your configure line is..?
[2009-07-08 14:17:45] leonard-php-bugs at ottolander dot nl
Description:
Building 5.2.9 on CentOS-4, although later versions until CVS today are
affected. The OS is not really relevant, just the reason there are no
unbundled headers available as there's a version mismatch with the
bundled headers.
Using the bundled pcre library by not supplying any pcre configure
options. When the unbundled (upgraded/matching)
#46130 [Com]: SOAP-ERROR: Parsing WSDL
ID: 46130 Comment by: sebasg37 at gmail dot com Reported By: cfelce at gmail dot com Status: No Feedback Bug Type: SOAP related Operating System: GNU/Linux Ubuntu fesity PHP Version: 5.2CVS-2008-09-19 (CVS) New Comment: Itis not neccesary to change the service for the standard one.. simply change this tag wsp:UsingPolicy wsdl:required=true/ to this one wsp:UsingPolicy wsdl:required=false/ Best Regards Sebastián Previous Comments: [2009-09-17 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-09-09 18:33:47] sjo...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. [2009-06-24 11:22:52] sjoerd-php at linuxonly dot nl Thank you for your bug report. The message Unknown required WSDL extension means that the WSDL uses some extension and specifies that the client MUST understand it in order to use the service. Appearantly, PHP SoapClient does not understand the extension, thus causing this error. Please provide the WSDL or information about the required extension. [2009-03-11 19:35:13] michael dot schramm at gmail dot com Same thing happens with PHP version 5.2.6: SOAP-ERROR: Parsing WSDL: Unknown required WSDL extension 'http://schemas.xmlsoap.org/ws/2004/09/policy' Changing the Service is not always an option! [2008-12-31 11:12:18] omabil at gmail dot com Hello everybody, the work-around we used to avoid this problem is by using the standard sap wsdl instead of the ws-policy one. By replacing the wspolicy word by standard in the url of the wsdl we've got a second wsdl which doesn't use the ws policies. Regards, -- Omabil 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/46130 -- Edit this bug report at http://bugs.php.net/?id=46130edit=1
#51125 [NEW]: a bug about mysql_pconnect
From: asersz at gmail dot com
Operating system: Windows 7
PHP version: 5.2.12
PHP Bug Type: MySQL related
Bug description: a bug about mysql_pconnect
Description:
I am not good at english.
My apache is running (Port 80).
URL is 'localhost:80' or 'localhost'.
Function : mysql_pconnect('localhost:80', 'root', '123');
then, no error and the function never return.
Thanks.
Reproduce code:
---
set_time_limit(0);
// make sure your apache is running (Port 80).
mysql_pconnect('localhost:80', 'root', '123');
Expected result:
Just like a loop ?
--
Edit bug report at http://bugs.php.net/?id=51125edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51125r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51125r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51125r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51125r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51125r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51125r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51125r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51125r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51125r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51125r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51125r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51125r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51125r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51125r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51125r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51125r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51125r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51125r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51125r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51125r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51125r=mysqlcfg
#51125 [Opn-Bgs]: a bug about mysql_pconnect
ID: 51125
Updated by: paj...@php.net
Reported By: asersz at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: MySQL related
Operating System: Windows 7
PHP Version: 5.2.12
New Comment:
See the other report about mysql and IPV6
Previous Comments:
[2010-02-23 15:27:23] asersz at gmail dot com
Description:
I am not good at english.
My apache is running (Port 80).
URL is 'localhost:80' or 'localhost'.
Function : mysql_pconnect('localhost:80', 'root', '123');
then, no error and the function never return.
Thanks.
Reproduce code:
---
set_time_limit(0);
// make sure your apache is running (Port 80).
mysql_pconnect('localhost:80', 'root', '123');
Expected result:
Just like a loop ?
--
Edit this bug report at http://bugs.php.net/?id=51125edit=1
#48853 [Opn-Fbk]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853
Updated by: j...@php.net
Reported By: leonard-php-bugs at ottolander dot nl
-Status: Open
+Status: Feedback
Bug Type: Compile Failure
Operating System: CentOS-4
PHP Version: 5.2CVS-2009-07-08 (CVS)
New Comment:
no feedback means you didn't provide the feedback from the correct
tab but failed and used Add Comment instead (the right place is Edit
Submission for you since you reported this).
Now, can you please provide the actual configure line? Something I can
copy'n'paste and which has ONLY the required options to reproduce this.
Note: I can not reproduce this with or without the pcre headers around..
Previous Comments:
[2010-02-23 14:18:28] leonard-php-bugs at ottolander dot nl
I am unsure why this report was labeled No Feedback as I provided the
requested configure line within 2 hours after the request was made. I
was not aware of this state change as I haven't received an email
indicting this.
Doing a quick checkup in SVN it seems this issue was not fixed. In
5.3.2 the block where $PHP_PCRE_REGEX = yes tests true got moved to
the bottom of the file, but the required include path still seems not to
be provided.
To shortly restate the issue:
On a system where no other pcre headers are available the headers of
the bundled pcre are not found due to a missing include path and the
build fails.
Since on most systems pcre headers will be available you will need to
explicitly remove the pcre headers provided by the build system
(pcre-devel package or similar) to reproduce this issue. If any other
pcre headers than the bundled ones are available on the system the build
will use those and succeed where it shouldn't.
Build still fails on CentOS(/RHEL)-4 for php-5.2.12. Old headers have
been removed using rpm -e --nodeps pcre-devel. I am aware this is an
unusual situation, but what is the point of building against the bundled
pcre source when the build uses the (old and wrong) headers provided by
the build system? PHP should find and use the headers of the bundled
pcre when building against these, not some random headers available on
the system.
[2009-07-08 22:29:16] leonard-php-bugs at ottolander dot nl
As I said, I'm not using a --with- or --without-pcre option. The other
options seem not very relevant in this context but I'll paste the line
from the used rpm spec file here. %configure translates to configure ;)
%configure \
--cache-file=../config.cache \
--with-libdir=%{_lib} \
--with-config-file-path=%{_sysconfdir} \
--with-config-file-scan-dir=%{_sysconfdir}/php.d \
--disable-debug \
--with-pic \
--disable-rpath \
--without-pear \
--with-bz2 \
--with-exec-dir=%{_bindir} \
--with-freetype-dir=%{_prefix} \
--with-png-dir=%{_prefix} \
--enable-gd-native-ttf \
--without-gdbm \
--with-gettext \
--with-gmp \
--with-iconv \
--with-jpeg-dir=%{_prefix} \
--with-openssl \
--with-zlib \
--with-layout=GNU \
--enable-exif \
--enable-ftp \
--enable-magic-quotes \
--enable-sockets \
--enable-sysvsem --enable-sysvshm --enable-sysvmsg \
--with-kerberos \
--enable-ucd-snmp-hack \
--enable-shmop \
--enable-calendar \
--without-mime-magic \
--without-sqlite \
--with-libxml-dir=%{_prefix} \
--enable-xml \
--with-system-tzdata \
$*
I'd say, just open ext/pcre/config0.m4 and see there's no
PHP_ADD_INCLUDE inside the second (nested) if that causes httpd.h to be
unable to locate pcreposix.h if no pcre headers are installed on the
system.
If there is already a local copy of the pcre headers installed the
-I/usr/include will cause the build to still find a (possible incorrect)
version of the headers, and it succeeds (if the versions are close
enough).
On my system these headers aren't available as on CentOS-4 they are
version 4.5, so I removed them. This is an unusual situation, which is
probably why nobody noticed this issue before (the local headers are
probably available on most systems because builds like apache depend on
them).
[2009-07-08 20:37:17] j...@php.net
And your configure line is..?
[2009-07-08 14:17:45] leonard-php-bugs at ottolander dot nl
Description:
Building 5.2.9 on CentOS-4, although later versions until CVS today are
affected. The OS is not really relevant, just the reason there are no
unbundled headers available as there's a version mismatch with the
bundled headers.
Using the bundled pcre library by not supplying any pcre configure
#48853 [Fbk-Opn]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853
User updated by: leonard-php-bugs at ottolander dot nl
Reported By: leonard-php-bugs at ottolander dot nl
-Status: Feedback
+Status: Open
Bug Type: Compile Failure
Operating System: CentOS-4
PHP Version: 5.2CVS-2009-07-08 (CVS)
New Comment:
I narrowed the offending configure option down to
--with-apxs2=/usr/sbin/apxs
Afaik I need to specify that option to build the apache module... Or am
I mistaken?
Previous Comments:
[2010-02-23 15:29:09] j...@php.net
no feedback means you didn't provide the feedback from the correct
tab but failed and used Add Comment instead (the right place is Edit
Submission for you since you reported this).
Now, can you please provide the actual configure line? Something I can
copy'n'paste and which has ONLY the required options to reproduce this.
Note: I can not reproduce this with or without the pcre headers around..
[2010-02-23 14:18:28] leonard-php-bugs at ottolander dot nl
I am unsure why this report was labeled No Feedback as I provided the
requested configure line within 2 hours after the request was made. I
was not aware of this state change as I haven't received an email
indicting this.
Doing a quick checkup in SVN it seems this issue was not fixed. In
5.3.2 the block where $PHP_PCRE_REGEX = yes tests true got moved to
the bottom of the file, but the required include path still seems not to
be provided.
To shortly restate the issue:
On a system where no other pcre headers are available the headers of
the bundled pcre are not found due to a missing include path and the
build fails.
Since on most systems pcre headers will be available you will need to
explicitly remove the pcre headers provided by the build system
(pcre-devel package or similar) to reproduce this issue. If any other
pcre headers than the bundled ones are available on the system the build
will use those and succeed where it shouldn't.
Build still fails on CentOS(/RHEL)-4 for php-5.2.12. Old headers have
been removed using rpm -e --nodeps pcre-devel. I am aware this is an
unusual situation, but what is the point of building against the bundled
pcre source when the build uses the (old and wrong) headers provided by
the build system? PHP should find and use the headers of the bundled
pcre when building against these, not some random headers available on
the system.
[2009-07-08 22:29:16] leonard-php-bugs at ottolander dot nl
As I said, I'm not using a --with- or --without-pcre option. The other
options seem not very relevant in this context but I'll paste the line
from the used rpm spec file here. %configure translates to configure ;)
%configure \
--cache-file=../config.cache \
--with-libdir=%{_lib} \
--with-config-file-path=%{_sysconfdir} \
--with-config-file-scan-dir=%{_sysconfdir}/php.d \
--disable-debug \
--with-pic \
--disable-rpath \
--without-pear \
--with-bz2 \
--with-exec-dir=%{_bindir} \
--with-freetype-dir=%{_prefix} \
--with-png-dir=%{_prefix} \
--enable-gd-native-ttf \
--without-gdbm \
--with-gettext \
--with-gmp \
--with-iconv \
--with-jpeg-dir=%{_prefix} \
--with-openssl \
--with-zlib \
--with-layout=GNU \
--enable-exif \
--enable-ftp \
--enable-magic-quotes \
--enable-sockets \
--enable-sysvsem --enable-sysvshm --enable-sysvmsg \
--with-kerberos \
--enable-ucd-snmp-hack \
--enable-shmop \
--enable-calendar \
--without-mime-magic \
--without-sqlite \
--with-libxml-dir=%{_prefix} \
--enable-xml \
--with-system-tzdata \
$*
I'd say, just open ext/pcre/config0.m4 and see there's no
PHP_ADD_INCLUDE inside the second (nested) if that causes httpd.h to be
unable to locate pcreposix.h if no pcre headers are installed on the
system.
If there is already a local copy of the pcre headers installed the
-I/usr/include will cause the build to still find a (possible incorrect)
version of the headers, and it succeeds (if the versions are close
enough).
On my system these headers aren't available as on CentOS-4 they are
version 4.5, so I removed them. This is an unusual situation, which is
probably why nobody noticed this issue before (the local headers are
probably available on most systems because builds like apache depend on
them).
[2009-07-08 20:37:17] j...@php.net
And your configure line is..?
[2009-07-08 14:17:45] leonard-php-bugs at ottolander dot nl
Description:
#51126 [NEW]: class_exists + namespaces
From: richard at rjharrison dot org
Operating system: linux
PHP version: 5.3.1
PHP Bug Type: Unknown/Other Function
Bug description: class_exists + namespaces
Description:
class_exists() is not calling my spl_autoload_register'ed function with a
fully qualified (namespaced) class name.
Because the input to my autoload function is not fully qualified, it
cannot load the class and class_exists return false; however, if I try to
instantiate the class that does not exist then the correct, fully
qualified class now passed to the autoloader: it correctly loads the class
and my code works.
Reproduce code:
---
// register my autoloader
use Foo\Things;
// This fails: my autoload function is called with $class = 'Things\Car'
if(class_exists('Things\Car')){
echo class exists!;
}else{
echo Weird?;
}
// This works: my autoload function is called with $class =
'Foo\Things\Car'
$x = new Things\Car();
Expected result:
class exists!
Actual result:
--
Weird?
--
Edit bug report at http://bugs.php.net/?id=51126edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51126r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51126r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51126r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51126r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51126r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51126r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51126r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51126r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51126r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51126r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51126r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51126r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51126r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51126r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51126r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51126r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51126r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51126r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51126r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51126r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51126r=mysqlcfg
#51126 [Opn-Bgs]: class_exists + namespaces
ID: 51126
Updated by: johan...@php.net
Reported By: richard at rjharrison dot org
-Status: Open
+Status: Bogus
-Bug Type: SPL related
+Bug Type: Unknown/Other Function
Operating System: linux
PHP Version: 5.3.1
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
When used as a string we need the fully qualified name as we don't know
where the parameter is coming from.
Previous Comments:
[2010-02-23 18:41:57] richard at rjharrison dot org
Description:
class_exists() is not calling my spl_autoload_register'ed function with
a fully qualified (namespaced) class name.
Because the input to my autoload function is not fully qualified, it
cannot load the class and class_exists return false; however, if I try
to instantiate the class that does not exist then the correct, fully
qualified class now passed to the autoloader: it correctly loads the
class and my code works.
Reproduce code:
---
// register my autoloader
use Foo\Things;
// This fails: my autoload function is called with $class =
'Things\Car'
if(class_exists('Things\Car')){
echo class exists!;
}else{
echo Weird?;
}
// This works: my autoload function is called with $class =
'Foo\Things\Car'
$x = new Things\Car();
Expected result:
class exists!
Actual result:
--
Weird?
--
Edit this bug report at http://bugs.php.net/?id=51126edit=1
#51127 [NEW]: $_SESSION illogical behaviour.
From: asanoki at gmail dot com
Operating system: Linux
PHP version: 5.2.12
PHP Bug Type: Session related
Bug description: $_SESSION illogical behaviour.
Description:
No warning about using not allowed characters as a key in array $_SESSION.
It is illogical, and should raise a warning or notice.
In manual it is written that $_SESSION is a superglobal *associative
array* (http://pl.php.net/manual/pl/reserved.variables.session.php).
Additional restrictions to key names are illogical and unintuitive. Why do
a session serialization function uses diffrent algorithm than default
serialize() php function which works fine in such situations?
Example. Using | character as a key in $_SESSION array causes damaging a
session file (it gets 0 bytes length) without any notice, warning or error.
I understand that it is mentioned in manual, but it is illogical,
unintuitive and should raise at least a warning.
Reproduce code:
---
/* Here is php code which reproduces this error. Fire it *twice*, and look
at output of a *second* execution. */
session_start();
echo This was loaded from session:br /\n;
var_dump($_SESSION);
$_SESSION[a|b] = asdasd;
echo br /\nThis is written to session:br /\n;
var_dump($_SESSION);
Expected result:
This was loaded from session:
array(1) { [a|b]= string(6) asdasd }
This is written to session:
array(1) { [a|b]= string(6) asdasd }
Actual result:
--
This was loaded from session:
array(0) { }
This is written to session:
array(1) { [a|b]= string(6) asdasd }
--
Edit bug report at http://bugs.php.net/?id=51127edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51127r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51127r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51127r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51127r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51127r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51127r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51127r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51127r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51127r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51127r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51127r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51127r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51127r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51127r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51127r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51127r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51127r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51127r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51127r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51127r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51127r=mysqlcfg
#51120 [Bgs]: If session var is NULL, value will be overwritten by global with same name
ID: 51120
User updated by: antonio04 at gmail dot com
Reported By: antonio04 at gmail dot com
Status: Bogus
Bug Type: Session related
Operating System: FreeBSD 7.2
PHP Version: 5.3.1
New Comment:
On further research, this seems due to the session.bug_compat_42
bug/feature. Turning this setting off in php.ini has resolved the
issue. Thanks.
Previous Comments:
[2010-02-23 13:13:24] antonio04 at gmail dot com
Just to confirm, register_globals is definitely off -- both as reported
by phpinfo() as well as the following snippet:
?php
echo 'register_globals = ' . ini_get('register_globals') . \n;
?
Which displays the following:
register_globals =
[2010-02-23 13:07:21] antonio04 at gmail dot com
Thanks for your quick response.
Sorry, I should have mentioned that register_globals is off in php.ini.
I included the ini_set line to illustrate that point, but I suppose
that's moot, since you can't set it via ini_set =)
However, the problem is still there... can you please try to reproduce
it?
[2010-02-23 12:55:53] j...@php.net
For starters, you can't set register_globals in script. Hence there's
no bug but expected (bad) behaviour on having register_globals = On.
Switch it off and all is well. :)
[2010-02-23 10:33:50] antonio04 at gmail dot com
Here are the expected/actual results:
Expected result:
Script 1:
Script 2:
NULL
Actual result:
--
Script 1:
Script 2:
string(3) bar
[2010-02-23 08:42:13] antonio04 at gmail dot com
Sorry, there was a typo in the reproduce code -- please check this
instead:
?php
/* Script one */
ini_set('register_globals', 0);
session_start();
$_SESSION['foo'] = NULL;
$foo = 'bar';
?
Then view the second script:
?php
/* Script two */
session_start();
var_dump($_SESSION['foo']);
?
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/51120
--
Edit this bug report at http://bugs.php.net/?id=51120edit=1
#51126 [Bgs]: class_exists + namespaces
ID: 51126
User updated by: richard at rjharrison dot org
Reported By: richard at rjharrison dot org
Status: Bogus
Bug Type: SPL related
Operating System: linux
PHP Version: 5.3.1
New Comment:
Hi Johannes,
I double-checked the documentation and found no mention that the string
passed to class_exists() must be fully qualified. Perhaps this is a
documentation bug.
It is certainly seems inconsistent/counter-intuitive:-
class_exists('Things\Car'); // FALSE, class does not exist
$car = new Things\Car(); // HUH? Class does exist after all
So PHP is able to figure out there is a use Foo/Things namespace in
effect on one line, but not on the other? Lame.
Previous Comments:
[2010-02-23 18:46:01] johan...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
When used as a string we need the fully qualified name as we don't know
where the parameter is coming from.
[2010-02-23 18:41:57] richard at rjharrison dot org
Description:
class_exists() is not calling my spl_autoload_register'ed function with
a fully qualified (namespaced) class name.
Because the input to my autoload function is not fully qualified, it
cannot load the class and class_exists return false; however, if I try
to instantiate the class that does not exist then the correct, fully
qualified class now passed to the autoloader: it correctly loads the
class and my code works.
Reproduce code:
---
// register my autoloader
use Foo\Things;
// This fails: my autoload function is called with $class =
'Things\Car'
if(class_exists('Things\Car')){
echo class exists!;
}else{
echo Weird?;
}
// This works: my autoload function is called with $class =
'Foo\Things\Car'
$x = new Things\Car();
Expected result:
class exists!
Actual result:
--
Weird?
--
Edit this bug report at http://bugs.php.net/?id=51126edit=1
#48853 [Opn-Fbk]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853
Updated by: sni...@php.net
Reported By: leonard-php-bugs at ottolander dot nl
-Status: Open
+Status: Feedback
Bug Type: Compile Failure
Operating System: CentOS-4
PHP Version: 5.2CVS-2009-07-08 (CVS)
New Comment:
Considering the error really happens inside Apache headers, how is this
a PHP bug? From your compile error:
/usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/mod_php5.c:26:
/usr/include/httpd/httpd.h:43:23: pcreposix.h: No such file or
directory
Blindly adding unnecessary include paths to fix something outside our
control is not very wise..
Previous Comments:
[2010-02-23 17:15:34] leonard-php-bugs at ottolander dot nl
I narrowed the offending configure option down to
--with-apxs2=/usr/sbin/apxs
Afaik I need to specify that option to build the apache module... Or am
I mistaken?
[2010-02-23 15:29:09] j...@php.net
no feedback means you didn't provide the feedback from the correct
tab but failed and used Add Comment instead (the right place is Edit
Submission for you since you reported this).
Now, can you please provide the actual configure line? Something I can
copy'n'paste and which has ONLY the required options to reproduce this.
Note: I can not reproduce this with or without the pcre headers around..
[2010-02-23 14:18:28] leonard-php-bugs at ottolander dot nl
I am unsure why this report was labeled No Feedback as I provided the
requested configure line within 2 hours after the request was made. I
was not aware of this state change as I haven't received an email
indicting this.
Doing a quick checkup in SVN it seems this issue was not fixed. In
5.3.2 the block where $PHP_PCRE_REGEX = yes tests true got moved to
the bottom of the file, but the required include path still seems not to
be provided.
To shortly restate the issue:
On a system where no other pcre headers are available the headers of
the bundled pcre are not found due to a missing include path and the
build fails.
Since on most systems pcre headers will be available you will need to
explicitly remove the pcre headers provided by the build system
(pcre-devel package or similar) to reproduce this issue. If any other
pcre headers than the bundled ones are available on the system the build
will use those and succeed where it shouldn't.
Build still fails on CentOS(/RHEL)-4 for php-5.2.12. Old headers have
been removed using rpm -e --nodeps pcre-devel. I am aware this is an
unusual situation, but what is the point of building against the bundled
pcre source when the build uses the (old and wrong) headers provided by
the build system? PHP should find and use the headers of the bundled
pcre when building against these, not some random headers available on
the system.
[2009-07-08 22:29:16] leonard-php-bugs at ottolander dot nl
As I said, I'm not using a --with- or --without-pcre option. The other
options seem not very relevant in this context but I'll paste the line
from the used rpm spec file here. %configure translates to configure ;)
%configure \
--cache-file=../config.cache \
--with-libdir=%{_lib} \
--with-config-file-path=%{_sysconfdir} \
--with-config-file-scan-dir=%{_sysconfdir}/php.d \
--disable-debug \
--with-pic \
--disable-rpath \
--without-pear \
--with-bz2 \
--with-exec-dir=%{_bindir} \
--with-freetype-dir=%{_prefix} \
--with-png-dir=%{_prefix} \
--enable-gd-native-ttf \
--without-gdbm \
--with-gettext \
--with-gmp \
--with-iconv \
--with-jpeg-dir=%{_prefix} \
--with-openssl \
--with-zlib \
--with-layout=GNU \
--enable-exif \
--enable-ftp \
--enable-magic-quotes \
--enable-sockets \
--enable-sysvsem --enable-sysvshm --enable-sysvmsg \
--with-kerberos \
--enable-ucd-snmp-hack \
--enable-shmop \
--enable-calendar \
--without-mime-magic \
--without-sqlite \
--with-libxml-dir=%{_prefix} \
--enable-xml \
--with-system-tzdata \
$*
I'd say, just open ext/pcre/config0.m4 and see there's no
PHP_ADD_INCLUDE inside the second (nested) if that causes httpd.h to be
unable to locate pcreposix.h if no pcre headers are installed on the
system.
If there is already a local copy of the pcre headers installed the
-I/usr/include will cause the build to still find a (possible incorrect)
version of the headers, and it succeeds (if the versions are close
enough).
On my system these headers aren't available as on CentOS-4 they are
version 4.5, so I removed them. This is an unusual
#51128 [NEW]: imagefill() doesn't work with large images
From: admin-team at suresupport dot com Operating system: Linux Debian 64bit PHP version: 5.2.12 PHP Bug Type: GD related Bug description: imagefill() doesn't work with large images Description: Hello, Please check this URL: http://imagefill.server260.com/ http://imagefill.server260.com/test1.php is working properly when the size of the image is 255x255 pixels and is producing a red rectangle http://imagefill.server260.com/test2.php is the same code with image size of 256x256 producing a black rectangle You should check http://imagefill.server260.com/info.php for the PHP options. Reproduce code: --- http://imagefill.server260.com/test1.source.txt http://imagefill.server260.com/test2.source.txt http://imagefill.server260.com/test.diff.txt Expected result: When I run http://imagefill.server260.com/test2.php I should get a red rectangle. Actual result: -- But I get a black rectangle. -- Edit bug report at http://bugs.php.net/?id=51128edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51128r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51128r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51128r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51128r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51128r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51128r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51128r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51128r=needscript Try newer version: http://bugs.php.net/fix.php?id=51128r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51128r=support Expected behavior: http://bugs.php.net/fix.php?id=51128r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51128r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51128r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51128r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51128r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51128r=dst IIS Stability: http://bugs.php.net/fix.php?id=51128r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51128r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51128r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51128r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51128r=mysqlcfg
#51128 [Opn-Fbk]: imagefill() doesn't work with large images
ID: 51128 Updated by: paj...@php.net Reported By: admin-team at suresupport dot com -Status: Open +Status: Feedback Bug Type: GD related Operating System: Linux Debian 64bit PHP Version: 5.2.12 New Comment: Please allocate a background and then a color to use for the fill. Previous Comments: [2010-02-23 21:09:38] admin-team at suresupport dot com Description: Hello, Please check this URL: http://imagefill.server260.com/ http://imagefill.server260.com/test1.php is working properly when the size of the image is 255x255 pixels and is producing a red rectangle http://imagefill.server260.com/test2.php is the same code with image size of 256x256 producing a black rectangle You should check http://imagefill.server260.com/info.php for the PHP options. Reproduce code: --- http://imagefill.server260.com/test1.source.txt http://imagefill.server260.com/test2.source.txt http://imagefill.server260.com/test.diff.txt Expected result: When I run http://imagefill.server260.com/test2.php I should get a red rectangle. Actual result: -- But I get a black rectangle. -- Edit this bug report at http://bugs.php.net/?id=51128edit=1
#48853 [Fbk-Opn]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853
User updated by: leonard-php-bugs at ottolander dot nl
Reported By: leonard-php-bugs at ottolander dot nl
-Status: Feedback
+Status: Open
Bug Type: Compile Failure
Operating System: CentOS-4
PHP Version: 5.2CVS-2009-07-08 (CVS)
New Comment:
The issue is that the apache headers that you include in the module
build expect the pcre headers in one of the default locations. Since we
build against the pcre library that you bundle you should provide that
extra path to those headers. You cannot expect apache to look for them
in an unknown build path and an unknown subdiretory.
Previous Comments:
[2010-02-23 19:59:38] sni...@php.net
Considering the error really happens inside Apache headers, how is this
a PHP bug? From your compile error:
/usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/mod_php5.c:26:
/usr/include/httpd/httpd.h:43:23: pcreposix.h: No such file or
directory
Blindly adding unnecessary include paths to fix something outside our
control is not very wise..
[2010-02-23 17:15:34] leonard-php-bugs at ottolander dot nl
I narrowed the offending configure option down to
--with-apxs2=/usr/sbin/apxs
Afaik I need to specify that option to build the apache module... Or am
I mistaken?
[2010-02-23 15:29:09] j...@php.net
no feedback means you didn't provide the feedback from the correct
tab but failed and used Add Comment instead (the right place is Edit
Submission for you since you reported this).
Now, can you please provide the actual configure line? Something I can
copy'n'paste and which has ONLY the required options to reproduce this.
Note: I can not reproduce this with or without the pcre headers around..
[2010-02-23 14:18:28] leonard-php-bugs at ottolander dot nl
I am unsure why this report was labeled No Feedback as I provided the
requested configure line within 2 hours after the request was made. I
was not aware of this state change as I haven't received an email
indicting this.
Doing a quick checkup in SVN it seems this issue was not fixed. In
5.3.2 the block where $PHP_PCRE_REGEX = yes tests true got moved to
the bottom of the file, but the required include path still seems not to
be provided.
To shortly restate the issue:
On a system where no other pcre headers are available the headers of
the bundled pcre are not found due to a missing include path and the
build fails.
Since on most systems pcre headers will be available you will need to
explicitly remove the pcre headers provided by the build system
(pcre-devel package or similar) to reproduce this issue. If any other
pcre headers than the bundled ones are available on the system the build
will use those and succeed where it shouldn't.
Build still fails on CentOS(/RHEL)-4 for php-5.2.12. Old headers have
been removed using rpm -e --nodeps pcre-devel. I am aware this is an
unusual situation, but what is the point of building against the bundled
pcre source when the build uses the (old and wrong) headers provided by
the build system? PHP should find and use the headers of the bundled
pcre when building against these, not some random headers available on
the system.
[2009-07-08 22:29:16] leonard-php-bugs at ottolander dot nl
As I said, I'm not using a --with- or --without-pcre option. The other
options seem not very relevant in this context but I'll paste the line
from the used rpm spec file here. %configure translates to configure ;)
%configure \
--cache-file=../config.cache \
--with-libdir=%{_lib} \
--with-config-file-path=%{_sysconfdir} \
--with-config-file-scan-dir=%{_sysconfdir}/php.d \
--disable-debug \
--with-pic \
--disable-rpath \
--without-pear \
--with-bz2 \
--with-exec-dir=%{_bindir} \
--with-freetype-dir=%{_prefix} \
--with-png-dir=%{_prefix} \
--enable-gd-native-ttf \
--without-gdbm \
--with-gettext \
--with-gmp \
--with-iconv \
--with-jpeg-dir=%{_prefix} \
--with-openssl \
--with-zlib \
--with-layout=GNU \
--enable-exif \
--enable-ftp \
--enable-magic-quotes \
--enable-sockets \
--enable-sysvsem --enable-sysvshm --enable-sysvmsg \
--with-kerberos \
--enable-ucd-snmp-hack \
--enable-shmop \
--enable-calendar \
--without-mime-magic \
--without-sqlite \
--with-libxml-dir=%{_prefix} \
--enable-xml \
--with-system-tzdata \
$*
I'd say, just open ext/pcre/config0.m4 and see there's no
PHP_ADD_INCLUDE
#48853 [Opn]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853 User updated by: leonard-php-bugs at ottolander dot nl Reported By: leonard-php-bugs at ottolander dot nl Status: Open Bug Type: Compile Failure Operating System: CentOS-4 PHP Version: 5.2CVS-2009-07-08 (CVS) New Comment: Btw, I'm not saying the proposed patch is the best place to fix this. You might want to fix this missing include path around where the option --with-apxs2 is parsed and set the include path there in case we build against the bundled pcre. But again, since only PHP knows the path to it's own bundled pcre headers it's PHP's task to make the path to those bundled headers available. Previous Comments: [2010-02-23 21:37:54] leonard-php-bugs at ottolander dot nl The issue is that the apache headers that you include in the module build expect the pcre headers in one of the default locations. Since we build against the pcre library that you bundle you should provide that extra path to those headers. You cannot expect apache to look for them in an unknown build path and an unknown subdiretory. [2010-02-23 19:59:38] sni...@php.net Considering the error really happens inside Apache headers, how is this a PHP bug? From your compile error: /usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/mod_php5.c:26: /usr/include/httpd/httpd.h:43:23: pcreposix.h: No such file or directory Blindly adding unnecessary include paths to fix something outside our control is not very wise.. [2010-02-23 17:15:34] leonard-php-bugs at ottolander dot nl I narrowed the offending configure option down to --with-apxs2=/usr/sbin/apxs Afaik I need to specify that option to build the apache module... Or am I mistaken? [2010-02-23 15:29:09] j...@php.net no feedback means you didn't provide the feedback from the correct tab but failed and used Add Comment instead (the right place is Edit Submission for you since you reported this). Now, can you please provide the actual configure line? Something I can copy'n'paste and which has ONLY the required options to reproduce this. Note: I can not reproduce this with or without the pcre headers around.. [2010-02-23 14:18:28] leonard-php-bugs at ottolander dot nl I am unsure why this report was labeled No Feedback as I provided the requested configure line within 2 hours after the request was made. I was not aware of this state change as I haven't received an email indicting this. Doing a quick checkup in SVN it seems this issue was not fixed. In 5.3.2 the block where $PHP_PCRE_REGEX = yes tests true got moved to the bottom of the file, but the required include path still seems not to be provided. To shortly restate the issue: On a system where no other pcre headers are available the headers of the bundled pcre are not found due to a missing include path and the build fails. Since on most systems pcre headers will be available you will need to explicitly remove the pcre headers provided by the build system (pcre-devel package or similar) to reproduce this issue. If any other pcre headers than the bundled ones are available on the system the build will use those and succeed where it shouldn't. Build still fails on CentOS(/RHEL)-4 for php-5.2.12. Old headers have been removed using rpm -e --nodeps pcre-devel. I am aware this is an unusual situation, but what is the point of building against the bundled pcre source when the build uses the (old and wrong) headers provided by the build system? PHP should find and use the headers of the bundled pcre when building against these, not some random headers available on the system. 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/48853 -- Edit this bug report at http://bugs.php.net/?id=48853edit=1
#48853 [Opn-Bgs]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853 Updated by: sni...@php.net Reported By: leonard-php-bugs at ottolander dot nl -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: CentOS-4 PHP Version: 5.2CVS-2009-07-08 (CVS) New Comment: You have deleted required header files and expect _PHP_ to fix it's configure to allow building against 3rd party headers _requiring_ those header files you have deleted, that's is quite insane. It's _APACHE_ requiring the headers, using the headers, needing the headers and linking to the specific library. (Try ldd httpd..) You can't just expect the bundled PCRE the be the correct one, can you? Now, thanks to our broken stuff you have found this problem in your system which you should fix. Previous Comments: [2010-02-23 21:58:45] leonard-php-bugs at ottolander dot nl Btw, I'm not saying the proposed patch is the best place to fix this. You might want to fix this missing include path around where the option --with-apxs2 is parsed and set the include path there in case we build against the bundled pcre. But again, since only PHP knows the path to it's own bundled pcre headers it's PHP's task to make the path to those bundled headers available. [2010-02-23 21:37:54] leonard-php-bugs at ottolander dot nl The issue is that the apache headers that you include in the module build expect the pcre headers in one of the default locations. Since we build against the pcre library that you bundle you should provide that extra path to those headers. You cannot expect apache to look for them in an unknown build path and an unknown subdiretory. [2010-02-23 19:59:38] sni...@php.net Considering the error really happens inside Apache headers, how is this a PHP bug? From your compile error: /usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/mod_php5.c:26: /usr/include/httpd/httpd.h:43:23: pcreposix.h: No such file or directory Blindly adding unnecessary include paths to fix something outside our control is not very wise.. [2010-02-23 17:15:34] leonard-php-bugs at ottolander dot nl I narrowed the offending configure option down to --with-apxs2=/usr/sbin/apxs Afaik I need to specify that option to build the apache module... Or am I mistaken? [2010-02-23 15:29:09] j...@php.net no feedback means you didn't provide the feedback from the correct tab but failed and used Add Comment instead (the right place is Edit Submission for you since you reported this). Now, can you please provide the actual configure line? Something I can copy'n'paste and which has ONLY the required options to reproduce this. Note: I can not reproduce this with or without the pcre headers around.. 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/48853 -- Edit this bug report at http://bugs.php.net/?id=48853edit=1
#51129 [NEW]: XX is not a valid Stream-Context resource while using Soap with local_cert
From: bigdan at gmail dot com Operating system: linux PHP version: 5.3.1 PHP Bug Type: Streams related Bug description: XX is not a valid Stream-Context resource while using Soap with local_cert Description: This bug is strangley similar to #46427, but not exactly the same. This bug _only_ manifests when using php 5.3/5.3.1 and php snapshots. In order to reproduce this bug, local_cert (and passphrase - unfortunately, I cannot test without the passphrase) need to specified in the SoapClient parameters. Any calls to this constructed client fail with: E_WARNING: SoapClient::__doRequest(): XX is not a valid Stream-Context resource in ... where XX is the resource number, which is missing a #. Using php 5.2.4-2ubuntu5.6, this exact same script works perfectly. This problem manifests regardless of whether the soap client is encapsulated in a function or procedural. Expected result: The SoapClient method executing successfully. Actual result: -- E_WARNING: SoapClient::__doRequest(): 179 is not a valid Stream-Context resource in ... -- Edit bug report at http://bugs.php.net/?id=51129edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51129r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51129r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51129r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51129r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51129r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51129r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51129r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51129r=needscript Try newer version: http://bugs.php.net/fix.php?id=51129r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51129r=support Expected behavior: http://bugs.php.net/fix.php?id=51129r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51129r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51129r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51129r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51129r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51129r=dst IIS Stability: http://bugs.php.net/fix.php?id=51129r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51129r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51129r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51129r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51129r=mysqlcfg
#51122 [Bgs]: the iteration on arrays with calling functions is very slow
ID: 51122
User updated by: y_kopel at walla dot com
Reported By: y_kopel at walla dot com
Status: Bogus
Bug Type: Arrays related
Operating System: linux
PHP Version: 5.3.1
New Comment:
but...
with and without gc_enable/gc_disable
it consume the same ammount of memory
but work 40 times longer with gc_enable
Previous Comments:
[2010-02-23 13:02:23] j...@php.net
Or run the script in 32bit system (and turn of GC :).
With latest SVN checkout of PHP_5_3:
$ src/build/php_5_3/sapi/cli/php -dmemory_limit=1G t.php
1.2259361743927
$ src/build/php_5_3/sapi/cli/php -dmemory_limit=1G -dzend.enable_gc=0
t.php
0.70840787887573
And with latest SVN checkout of PHP_5_2:
$ src/build/php_5_2/sapi/cli/php -dmemory_limit=1G t.php
0.69131684303284
Not noticeable even.
[2010-02-23 12:59:02] j...@php.net
Just turn off garbage collection if this is a problem for you.
(zend.enable_gc = off in php.ini)
[2010-02-23 11:54:00] y_kopel at walla dot com
shorter code:
?php
for ($i = 0 ;$i 100 ; $i++){
$users[$i]['SUM'] = 2;
}
$start = microtime(true);
$sum = 0;
foreach ($users as $u){
if ($u['SUM'] 1){ $sum++;}
}
echo microtime(true) - $start.\n;
?
OUTPUT
==
php 5.2.1
=
0.328261852264
php 5.3.1
=
42.350708961487
[2010-02-23 11:40:36] y_kopel at walla dot com
Description:
the iteration on arrays with calling functions is very slow
comparing php 5.2.1 to 5.3.1
Reproduce code:
---
?php
define(FLOATING_POINT,6);
function ww($f){
echo sprintf(%..FLOATING_POINT.f, $f).\n;
}
class A{
protected $users;
function __construct(){
for ($i = 0 ;$i 10 ; $i++){
$this-users[$i]['ELEMENT'] = array(a,b);
$this-users[$i]['SUM'] = 2;
}
}
function check_more_than_one_element(){
$sum = 0;
foreach ($this-users as $u){
if (count($u['ELEMENT']) 1){
$sum++;
}
}
return $sum;
}
function a_check_more_than_one_element(){
$sum = 0;
foreach ($this-users as $u){
if ($u['SUM'] 1){
$sum++;
}
}
return $sum;
}
}
$a = new A();
$start = microtime(true);
echo -\n;
for ($i = 0 ;$i 5 ; $i++){
$a-check_more_than_one_element();
$a-check_more_than_one_element();
$a-check_more_than_one_element();
$a-check_more_than_one_element();
}
echo -\n;
echo microtime(true) - $start.\n;
$a = new A();
$start = microtime(true);
echo -\n;
for ($i = 0 ;$i 5 ; $i++){
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
}
echo -\n;
echo microtime(true) - $start.\n;
?
Expected result:
php 5.2.1
=
-
-
1.75261092186
-
-
1.05390191078
Actual result:
--
php 5.3.1
=
-
-
58.992564916611
-
-
30.829360961914
--
Edit this bug report at http://bugs.php.net/?id=51122edit=1
#51122 [Bgs]: the iteration on arrays with calling functions is very slow
ID: 51122
Updated by: ras...@php.net
Reported By: y_kopel at walla dot com
Status: Bogus
Bug Type: Arrays related
Operating System: linux
PHP Version: 5.3.1
New Comment:
With gc on there are gc checks on every iteration. Just because it
doesn't use more memory doesn't mean that gc does add more overhead.
Previous Comments:
[2010-02-24 06:57:03] y_kopel at walla dot com
but...
with and without gc_enable/gc_disable
it consume the same ammount of memory
but work 40 times longer with gc_enable
[2010-02-23 13:02:23] j...@php.net
Or run the script in 32bit system (and turn of GC :).
With latest SVN checkout of PHP_5_3:
$ src/build/php_5_3/sapi/cli/php -dmemory_limit=1G t.php
1.2259361743927
$ src/build/php_5_3/sapi/cli/php -dmemory_limit=1G -dzend.enable_gc=0
t.php
0.70840787887573
And with latest SVN checkout of PHP_5_2:
$ src/build/php_5_2/sapi/cli/php -dmemory_limit=1G t.php
0.69131684303284
Not noticeable even.
[2010-02-23 12:59:02] j...@php.net
Just turn off garbage collection if this is a problem for you.
(zend.enable_gc = off in php.ini)
[2010-02-23 11:54:00] y_kopel at walla dot com
shorter code:
?php
for ($i = 0 ;$i 100 ; $i++){
$users[$i]['SUM'] = 2;
}
$start = microtime(true);
$sum = 0;
foreach ($users as $u){
if ($u['SUM'] 1){ $sum++;}
}
echo microtime(true) - $start.\n;
?
OUTPUT
==
php 5.2.1
=
0.328261852264
php 5.3.1
=
42.350708961487
[2010-02-23 11:40:36] y_kopel at walla dot com
Description:
the iteration on arrays with calling functions is very slow
comparing php 5.2.1 to 5.3.1
Reproduce code:
---
?php
define(FLOATING_POINT,6);
function ww($f){
echo sprintf(%..FLOATING_POINT.f, $f).\n;
}
class A{
protected $users;
function __construct(){
for ($i = 0 ;$i 10 ; $i++){
$this-users[$i]['ELEMENT'] = array(a,b);
$this-users[$i]['SUM'] = 2;
}
}
function check_more_than_one_element(){
$sum = 0;
foreach ($this-users as $u){
if (count($u['ELEMENT']) 1){
$sum++;
}
}
return $sum;
}
function a_check_more_than_one_element(){
$sum = 0;
foreach ($this-users as $u){
if ($u['SUM'] 1){
$sum++;
}
}
return $sum;
}
}
$a = new A();
$start = microtime(true);
echo -\n;
for ($i = 0 ;$i 5 ; $i++){
$a-check_more_than_one_element();
$a-check_more_than_one_element();
$a-check_more_than_one_element();
$a-check_more_than_one_element();
}
echo -\n;
echo microtime(true) - $start.\n;
$a = new A();
$start = microtime(true);
echo -\n;
for ($i = 0 ;$i 5 ; $i++){
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
$a-a_check_more_than_one_element();
}
echo -\n;
echo microtime(true) - $start.\n;
?
Expected result:
php 5.2.1
=
-
-
1.75261092186
-
-
1.05390191078
Actual result:
--
php 5.3.1
=
-
-
58.992564916611
-
-
30.829360961914
--
Edit this bug report at http://bugs.php.net/?id=51122edit=1
#51122 [Bgs]: the iteration on arrays with calling functions is very slow
ID: 51122
User updated by: y_kopel at walla dot com
Reported By: y_kopel at walla dot com
Status: Bogus
Bug Type: Arrays related
Operating System: linux
PHP Version: 5.3.1
New Comment:
so... maybe it worth to erite an optimization on it?
Previous Comments:
[2010-02-24 06:59:31] ras...@php.net
With gc on there are gc checks on every iteration. Just because it
doesn't use more memory doesn't mean that gc doesn't add more overhead
[2010-02-24 06:57:03] y_kopel at walla dot com
but...
with and without gc_enable/gc_disable
it consume the same ammount of memory
but work 40 times longer with gc_enable
[2010-02-23 13:02:23] j...@php.net
Or run the script in 32bit system (and turn of GC :).
With latest SVN checkout of PHP_5_3:
$ src/build/php_5_3/sapi/cli/php -dmemory_limit=1G t.php
1.2259361743927
$ src/build/php_5_3/sapi/cli/php -dmemory_limit=1G -dzend.enable_gc=0
t.php
0.70840787887573
And with latest SVN checkout of PHP_5_2:
$ src/build/php_5_2/sapi/cli/php -dmemory_limit=1G t.php
0.69131684303284
Not noticeable even.
[2010-02-23 12:59:02] j...@php.net
Just turn off garbage collection if this is a problem for you.
(zend.enable_gc = off in php.ini)
[2010-02-23 11:54:00] y_kopel at walla dot com
shorter code:
?php
for ($i = 0 ;$i 100 ; $i++){
$users[$i]['SUM'] = 2;
}
$start = microtime(true);
$sum = 0;
foreach ($users as $u){
if ($u['SUM'] 1){ $sum++;}
}
echo microtime(true) - $start.\n;
?
OUTPUT
==
php 5.2.1
=
0.328261852264
php 5.3.1
=
42.350708961487
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/51122
--
Edit this bug report at http://bugs.php.net/?id=51122edit=1
#50896 [Opn-Fbk]: Bus error on execution on a MIPS system
ID: 50896 Updated by: ahar...@php.net Reported By: angel at wututu dot com -Status: Open +Status: Feedback -Bug Type: Feature/Change Request +Bug Type: Reproducible crash Operating System: GNU/Linux PHP Version: 5.2snapshot-201002171530 New Comment: I can't reproduce this on a Debian testing install within a mipsel QEMU VM: the current PHP 5.2 and 5.3 SVN branches compile and appear to work normally, at least for trivial scripts. So, a few questions: Are you only seeing the Bus Errors on the actual MIPS devices, or within QEMU as well? Are you using a particular Linux distribution? Which machine type are you emulating with QEMU (ie what -M option, if any, are you passing to qemu-system-mipsel)? Have you tried a minimal build without any extensions enabled (ie just ./configure --enable-debug)? Does PHP still Bus Error out in that case? (If PHP works OK without any extensions, then it would be incredibly helpful if you were able to narrow down the problem to a particular extension that causes PHP to crash when it's compiled in.) Previous Comments: [2010-02-22 16:09:02] angel at wututu dot com Well... not cross compiling. I'm compiling it natively inside a virtual machine because I can't use the final machine because it lacks memory. [2010-02-19 08:34:06] j...@php.net -Status: Open +Status: Bogus Oh, you're cross-compiling this. We do not support that out-of-box, you're totally on your own with it. [2010-02-18 08:38:03] angel at wututu dot com -Status: Feedback +Status: Open -PHP Version: 5.3SVN-2010-02-10 +PHP Version: 5.2snapshot-201002171530 The backtrace in this case is more or less the same as before: (gdb) run Starting program: /build/php5.2-201002171530/sapi/cli/php warning: no loadable sections found in added symbol-file /usr/lib/libiconv.so.2 Program received signal SIGBUS, Bus error. 0x0071e704 in _zend_mm_alloc_int (heap=0x91f300, size=13) at /build/php5.2-201002171530/Zend/zend_alloc.c:1897 1897ZEND_MM_CHECK_BLOCK_LINKAGE(best_fit); (gdb) backtrace #0 0x0071e704 in _zend_mm_alloc_int (heap=0x91f300, size=13) at /build/php5.2-201002171530/Zend/zend_alloc.c:1897 #1 0x0074a5b4 in zend_register_functions (scope=0x0, functions=0x911ad0, function_table=value optimized out, type=value optimized out) at /build/php5.2-201002171530/Zend/zend_operators.h:287 #2 0x0074358c in zend_startup (utility_functions=value optimized out, extensions=value optimized out, start_builtin_functions=1) at /build/php5.2-201002171530/Zend/zend.c:676 #3 0x006ead00 in php_module_startup (sf=value optimized out, additional_modules=0x0, num_additional_modules=0) at /build/php5.2-201002171530/main/main.c:1710 #4 0x007ef254 in php_cli_startup (sapi_module=0x0) at /build/php5.2-201002171530/sapi/cli/php_cli.c:389 #5 0x007efdd8 in main (argc=1, argv=0x7f948dc4) at /build/php5.2-201002171530/sapi/cli/php_cli.c:748 [2010-02-17 15:59:17] j...@php.net Is the gdb backtrace same for it? Does it happen with latest PHP-5.2 snapshot? (found at http://snaps.php.net/ ) ? [2010-02-01 17:25:29] angel at wututu dot com Still the same error with the snapshot: Generating phar.php /bin/sh: line 1: 29472 Bus error ` if test -x /build/php5.3-201002010930/sapi/cli/php; then /build/php5.3-201002010930/build/shtool echo -n -- /build/php5.3-201002010930/sapi/cli/php -n; if test x != x; then /build/php5.3-201002010930/build/shtool echo -n -- -d extension_dir=/build/php5.3-201002010930/modules; for i in bz2 zlib phar; do if test -f /build/php5.3-201002010930/modules/$i.la; then . /build/php5.3-201002010930/modules/$i.la; /build/php5.3-201002010930/build/shtool echo -n -- -d extension=$dlname; fi; done; fi; else /build/php5.3-201002010930/build/shtool echo -n -- /build/php5.3-201002010930/sapi/cli/php; fi;` -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' -d phar.readonly=0 -d 'safe_mode=0' /build/php5.3-201002010930/ext/phar/build_precommand.php ext/phar/phar.php make: *** [ext/phar/phar.php] Error 138 And when being run: root@(none):/build/php5.3-201002010930# ./sapi/cli/php Bus error Let's see if someone can fix it or at least point me how to fix it. 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/50896 -- Edit this bug report at http://bugs.php.net/?id=50896edit=1
