#46457 [Fbk->Csd]: PDO+MySQL 5.1 gets empty username if password is empty
ID: 46457
User updated by: spam04 at pornel dot net
Reported By: spam04 at pornel dot net
-Status: Feedback
+Status: Closed
Bug Type: PDO related
Operating System: Mac OS X 10.5.5
PHP Version: 5.3CVS-2008-11-01 (snap)
Assigned To: mysql
New Comment:
I can't reproduce this anymore either, so this must have been some
weird glitch.
Thanks for looking into it.
Previous Comments:
[2008-11-17 17:14:13] [EMAIL PROTECTED]
I can't reproduce, I assume it's an issue within the server or
libmysql. Would the empty password be correct or is it just lost for the
error message?
Could you also try changing pdo_mysql_handle_factory() in
ext/pdo_mysql/mysql_driver.c so that
if (mysql_real_connect(H->server, host, dbh->username,
dbh->password, dbname, port, unix_socket, connect_opts) == NULL) {
pdo_mysql_error(dbh);
goto cleanup;
}
reads something like (adding a php_printf() call)
if (mysql_real_connect(H->server, host, dbh->username,
dbh->password, dbname, port, unix_socket, connect_opts) == NULL) {
php_printf("User: %s", dbh->username);
pdo_mysql_error(dbh);
goto cleanup;
}
and then recompile PHP?
The username is then printed in case of an error so we can verify it
isn't lost. If that username is correct it's a MySQL issue, else I'd
have to do further investigation on PHP side.
[2008-11-01 18:11:06] spam04 at pornel dot net
(fixed summary)
[2008-11-01 18:10:18] spam04 at pornel dot net
Description:
When connecting to MySQL 5.1 (mysql-5.1.29-rc-osx10.5-x86_64 to be
exact) with empty password in PDO::__construct(), MySQL receives empty
username.
Seems like bug #43493 (I've tried on snapshot from 10 minutes ago, so
it's not fixed in CVS, at least not for MySQL)
Actual result:
--
new PDO("mysql:dbname=database","username",'');
results in:
SQLSTATE[42000] [1044] Access denied for user ''@'localhost' to
database 'database'
Note that MySQL got empty username.
However:
$dest_db = new PDO("mysql:dbname=database","username",'password');
gives expected error:
SQLSTATE[28000] [1045] Access denied for user 'username'@'localhost'
(using password: YES)
--
Edit this bug report at http://bugs.php.net/?id=46457&edit=1
#46649 [NEW]: Setting array element with that same array produces inconsistent results
From: binarysurgeon at gmail dot com
Operating system: Linux 2.6
PHP version: 5.2.6
PHP Bug Type: *General Issues
Bug description: Setting array element with that same array produces
inconsistent results
Description:
When setting an a particular array element to the array itself, results
are different when it's inside a function vs outside the function.
Reproduce code:
---
function func()
{
$a[1] = '1';
$a[0] = $a;
var_dump($a);
}
func();
$a[1] = '1';
$a[0] = $a;
var_dump($a);
Expected result:
I'm not sure what to expect but at the vary least, the results should be
consistent. Results were consistent in 5.2.1.
array(2) {
[1]=>
string(1) "1"
[0]=>
array(1) {
[1]=>
string(1) "1"
}
}
array(2) {
[1]=>
string(1) "1"
[0]=>
array(1) {
[1]=>
string(1) "1"
}
}
Actual result:
--
array(2) {
[1]=>
string(1) "1"
[0]=>
NULL
}
array(2) {
[1]=>
string(1) "1"
[0]=>
array(1) {
[1]=>
string(1) "1"
}
}
--
Edit bug report at http://bugs.php.net/?id=46649&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46649&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46649&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46649&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46649&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46649&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46649&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46649&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46649&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46649&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46649&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46649&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46649&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46649&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46649&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46649&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46649&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46649&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46649&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46649&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46649&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46649&r=mysqlcfg
#46648 [Opn->Fbk]: Cannot redeclare declared function
ID: 46648
Updated by: [EMAIL PROTECTED]
Reported By: satovey at yahoo dot com
-Status: Open
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: Win98
PHP Version: 5.2.6
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2008-11-22 22:48:54] satovey at yahoo dot com
Description:
PHP seems to think that a function is redeclared.
1) This is the first function declared.
2) This is not occurring with any other declared functions.
3) This error occurs even when the entire function is placed
on a single line.
4) The error occurs on this function call whether it is in
the given file or inside an include file.
Reproduce code:
---
This is the system
Win98 running the following.
Apache Version
Apache/2.2.9 (Win32)
DAV/2 mod_ssl/2.2.9
OpenSSL/0.9.8h mod_autoindex_color
PHP/5.2.6
xampp version Version 1.6.7
Here is the error message.
Fatal error: Cannot redeclare getadminmodules()
(previously declared in
C:\xampp\htdocs\oldwebsite\YevotasSite\YevotasSite.php:26)
in C:\xampp\htdocs\oldwebsite\YevotasSite\YevotasSite.php on
line 26
Code for line 26 is as follows:
function getadminmodules(){}
Expected result:
The syntax is correct and therefore no errors are expected.
Actual result:
--
Fatal error occurs.
--
Edit this bug report at http://bugs.php.net/?id=46648&edit=1
#46648 [NEW]: Cannot redeclare declared function
From: satovey at yahoo dot com
Operating system: Win98
PHP version: 5.2.6
PHP Bug Type: Unknown/Other Function
Bug description: Cannot redeclare declared function
Description:
PHP seems to think that a function is redeclared.
1) This is the first function declared.
2) This is not occurring with any other declared functions.
3) This error occurs even when the entire function is placed
on a single line.
4) The error occurs on this function call whether it is in
the given file or inside an include file.
Reproduce code:
---
This is the system
Win98 running the following.
Apache Version
Apache/2.2.9 (Win32)
DAV/2 mod_ssl/2.2.9
OpenSSL/0.9.8h mod_autoindex_color
PHP/5.2.6
xampp version Version 1.6.7
Here is the error message.
Fatal error: Cannot redeclare getadminmodules()
(previously declared in
C:\xampp\htdocs\oldwebsite\YevotasSite\YevotasSite.php:26)
in C:\xampp\htdocs\oldwebsite\YevotasSite\YevotasSite.php on
line 26
Code for line 26 is as follows:
function getadminmodules(){}
Expected result:
The syntax is correct and therefore no errors are expected.
Actual result:
--
Fatal error occurs.
--
Edit bug report at http://bugs.php.net/?id=46648&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46648&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46648&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46648&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46648&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46648&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46648&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46648&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46648&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46648&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46648&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46648&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46648&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46648&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46648&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46648&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46648&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46648&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46648&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46648&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46648&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46648&r=mysqlcfg
#46629 [Fbk->Opn]: is_dir returns incorrect result
ID: 46629 User updated by: j-e dot zwar at bigpond dot net dot au Reported By: j-e dot zwar at bigpond dot net dot au -Status: Feedback +Status: Open Bug Type: Directory function related Operating System: Windows XP PRO SP3 PHP Version: 5.2.6 New Comment: Thanks for the advice. I changed the permissions and now the lowest level returns TRUE but not the "My Documents" level?? I.e., "C:/Documents and Settings/Fred & Ginger/My Documents/AC Images Test" returns TRUE but "C:/Documents and Settings/Fred & Ginger/My Documents" still returns FALSE. I right-clicked on the directory in Windows Explorer and within the Security tag entered IUSR_COMPUTERNAME (with my computer name) and then ticked the 'full control' box. Any other advice will be appreciated. Previous Comments: [2008-11-20 19:19:48] [EMAIL PROTECTED] Check permissions. [2008-11-20 11:26:55] j-e dot zwar at bigpond dot net dot au Description: PHP function is_dir does not recognise some of the directories in my PC directory structure. Environment is: . Dell Core 2 Duo PC . Windows XP Pro SP3 . PHP version 5.2.6 . IIS version 5.1 . MySQL version 5.0.51b-community-nt . Dreamweaver MX2004 version 7 as the "text editor" . Internet Explorer version 6.0.2900 . sendmail.exe All running on the Dell PC - i.e., all executions are via 'localhost' Reproduce code: --- $dir1 = "C:/AAImages/"; $dir2 = "C:/Documents and Settings/"; $dir3 = "C:/Documents and Settings/Fred & Ginger/"; $dir4 = "C:/Documents and Settings/Fred & Ginger/My Documents/"; $dir5 = "C:/Documents and Settings/Fred & Ginger/My Documents/AC Images Test/"; var_dump (is_dir($dir1)); // returns true (correctly) var_dump (is_dir($dir2)); // returns true (correctly) var_dump (is_dir($dir3)); // returns true (correctly) var_dump (is_dir($dir4)); // returns false (incorrectly) var_dump (is_dir($dir5)); // returns false (incorrectly) But all these directories do exist on my PC and I have checked the spelling carefully. Permissions seem to be OK as I can upload files from the lower level directories via an HTML form OK. Expected result: var_dump (is_dir($dir4)) and var_dump(is_dir($dir5)) should both return TRUE, i.e., all of the 5 var_dumps should return TRUE. Have tried it inversely and the same error is apparent - i.e., tried var_dump(!is_dir($dir4)) etc. With the 'not' tests I get false, false, false, true and true. Have also tried it with double backslashes in the directory names instead of the single forward slashes - same error apparent. Have also tried it without the trailing forward slash at the end of each directory name with the same erroneous result. Actual result: -- var_dump (is_dir($dir1)); // returns true (correctly) var_dump (is_dir($dir2)); // returns true (correctly) var_dump (is_dir($dir3)); // returns true (correctly) var_dump (is_dir($dir4)); // returns false (incorrectly) var_dump (is_dir($dir5)); // returns false (incorrectly) Any help/advice will be very much appreciated. Thank you in anticipation. -- Edit this bug report at http://bugs.php.net/?id=46629&edit=1
#44154 [Tbd->Csd]: PDO->errorInfo() does not always return three element array
ID: 44154
Updated by: [EMAIL PROTECTED]
Reported By: uwendel at mysql dot com
-Status: To be documented
+Status: Closed
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-02-18 (CVS)
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Previous Comments:
[2008-11-04 18:29:33] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Ok I have applied the patch to 5_3 and HEAD.
[2008-11-01 13:52:55] [EMAIL PROTECTED]
I have a very small patch that I could commit if someone else agrees.
http://dev.agoraproduction.com/php/5_3/ext/pdo/bug44154.patch
[2008-02-18 18:25:09] uwendel at mysql dot com
Description:
According to the manual one can expect PDO->errorInfo() to return an
array with three elements.
"Return Values
PDO->errorInfo() returns an array of error information about the last
operation performed by this database handle. The array consists of the
following fields:
Element Information
0 SQLSTATE error code (a five-character alphanumeric identifier
defined in the ANSI SQL standard).
1 Driver-specific error code.
2 Driver-specific error message."
http://www.php.net/manual/en/function.PDO-errorInfo.php
The manual is wrong. PDO will not always return an array with three
elements. There are two situations when you will get an array with only
one element.
1) driver has not set an error code yet
2) IM001 - not implemented (= driver can't set an error code)
I'd appreciate if you either document this or fix PDO->errorInfo() to
always return an array with three elements. My personal preference is
change PDO->errorInfo(). I don't see any reason why people would have to
use a complicated test like the following to avoid "undefined index"
style messages:
if (count($info = $pdo->errorInfo()) == 3)
die(sprintf("SQLSTATE %s, Driver info: %s/%s", $info[0], $info[1],
$info[2]));
else
die(sprintf("SQLSTATE %s", $info[0]));
Note that this bug is somewhat related to the question raised in
http://bugs.php.net/bug.php?id=44153 .
Reproduce code:
---
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("sqlite:/tmp/foo.db"); var_dump($pdo->errorCode());
var_dump($pdo->errorInfo());'
string(0) ""
array(1) {
[0]=>
string(0) ""
}
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("mysql:dbname=phptest;unix_socket=/tmp/mysql.sock", "root", "root");
$pdo->getAttribute(-1); var_dump($pdo->errorCode());
var_dump($pdo->errorInfo());'
Warning: PDO::getAttribute(): SQLSTATE[IM001]: Driver does not support
this function: driver does not support that attribute in Command line
code on line 1
string(5) "IM001"
array(1) {
[0]=>
string(5) "IM001"
}
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("sqlite:/tmp/foo.db"); $pdo->getAttribute(-1);
var_dump($pdo->errorCode()); var_dump($pdo->errorInfo());'
Warning: PDO::getAttribute(): SQLSTATE[IM001]: Driver does not support
this function: driver does not support that attribute in Command line
code on line 1
string(5) "IM001"
array(1) {
[0]=>
string(5) "IM001"
}
Expected result:
Always return an array with three elements. Make checking the
errorInfo() easier.
Actual result:
--
See above. Array with only one element.
--
Edit this bug report at http://bugs.php.net/?id=44154&edit=1
#44153 [Tbd->Csd]: PDO->errorCode() returns '' instead of SQLSTATE if no operation has been run
ID: 44153
Updated by: [EMAIL PROTECTED]
Reported By: uwendel at mysql dot com
-Status: To be documented
+Status: Closed
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-02-18 (CVS)
Assigned To: davidc
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Previous Comments:
[2008-11-22 20:16:32] [EMAIL PROTECTED]
Documentation has been updated.
[2008-11-04 18:30:22] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2008-11-01 19:57:42] [EMAIL PROTECTED]
The patch below allows you to do:
$error = $pdo->errorCode();
if (is_null($error)) {
// There's an empty error...
}
http://dev.agoraproduction.com/php/5_3/ext/pdo/bug44153.patch
More I look at it and more I think we should have a generic message
like "UNUSED" or something similar but I think NULL is also quite
straightforward.
[2008-10-24 23:34:18] [EMAIL PROTECTED]
What about returning NULL ? You could easily check the results using
is_null() and if it's null that means there's no errorCode().
Whereas when there's an error code you'll get the usual sqlstate
message/code.
What do you think? I think NULL would make great sense.
[2008-02-18 18:07:53] uwendel at mysql dot com
Description:
The PHP manual states that PDO->errorCode() returns the SQLSTATE
associated with the last operation run on the handle,
http://www.php.net/manual/en/function.PDO-errorCode.php
"Return Values
Returns a SQLSTATE, a five-character alphanumeric identifier defined in
the ANSI SQL-92 standard. Briefly, an SQLSTATE consists of a
two-character class value followed by a three-character subclass value.
A class value of 01 indicates a warning and is accompanied by a return
code of SQL_SUCCESS_WITH_INFO. Class values other than '01', except for
the class 'IM', indicate an error. The class 'IM' is specific to
warnings and errors that derive from the implementation of PDO (or
perhaps ODBC, if you're using the ODBC driver) itself. The subclass
value '000' in any class indicates that there is no subclass for that
SQLSTATE. "
What is PDO->errorCode() supposed to return if no operation has been
run on the handle yet?
If its valid to return any empty string, please add this to the
documentation.
Reproduce code:
---
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("mysql:dbname=phptest;unix_socket=/tmp/mysql.sock", "root", "root");
var_dump($pdo->errorCode());'
string(0) ""
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("sqlite:/tmp/foo.db"); var_dump($pdo->errorCode());'
string(0) ""
Expected result:
Its a matter of taste. Personally I have a preference for returning
'0' as this makes checking the error code easier but this would be
sort of a BC break.
Actual result:
--
Empty string (see above).
--
Edit this bug report at http://bugs.php.net/?id=44153&edit=1
#44153 [Tbd]: PDO->errorCode() returns '' instead of SQLSTATE if no operation has been run
ID: 44153
Updated by: [EMAIL PROTECTED]
Reported By: uwendel at mysql dot com
Status: To be documented
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-02-18 (CVS)
Assigned To: davidc
New Comment:
Documentation has been updated.
Previous Comments:
[2008-11-04 18:30:22] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2008-11-01 19:57:42] [EMAIL PROTECTED]
The patch below allows you to do:
$error = $pdo->errorCode();
if (is_null($error)) {
// There's an empty error...
}
http://dev.agoraproduction.com/php/5_3/ext/pdo/bug44153.patch
More I look at it and more I think we should have a generic message
like "UNUSED" or something similar but I think NULL is also quite
straightforward.
[2008-10-24 23:34:18] [EMAIL PROTECTED]
What about returning NULL ? You could easily check the results using
is_null() and if it's null that means there's no errorCode().
Whereas when there's an error code you'll get the usual sqlstate
message/code.
What do you think? I think NULL would make great sense.
[2008-02-18 18:07:53] uwendel at mysql dot com
Description:
The PHP manual states that PDO->errorCode() returns the SQLSTATE
associated with the last operation run on the handle,
http://www.php.net/manual/en/function.PDO-errorCode.php
"Return Values
Returns a SQLSTATE, a five-character alphanumeric identifier defined in
the ANSI SQL-92 standard. Briefly, an SQLSTATE consists of a
two-character class value followed by a three-character subclass value.
A class value of 01 indicates a warning and is accompanied by a return
code of SQL_SUCCESS_WITH_INFO. Class values other than '01', except for
the class 'IM', indicate an error. The class 'IM' is specific to
warnings and errors that derive from the implementation of PDO (or
perhaps ODBC, if you're using the ODBC driver) itself. The subclass
value '000' in any class indicates that there is no subclass for that
SQLSTATE. "
What is PDO->errorCode() supposed to return if no operation has been
run on the handle yet?
If its valid to return any empty string, please add this to the
documentation.
Reproduce code:
---
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("mysql:dbname=phptest;unix_socket=/tmp/mysql.sock", "root", "root");
var_dump($pdo->errorCode());'
string(0) ""
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("sqlite:/tmp/foo.db"); var_dump($pdo->errorCode());'
string(0) ""
Expected result:
Its a matter of taste. Personally I have a preference for returning
'0' as this makes checking the error code easier but this would be
sort of a BC break.
Actual result:
--
Empty string (see above).
--
Edit this bug report at http://bugs.php.net/?id=44153&edit=1
#46647 [NEW]: SplFileObject->fgetcsv() segfaults when passing 0 as argument
From: felipensp at gmail dot com Operating system: PHP version: 6CVS-2008-11-22 (CVS) PHP Bug Type: SPL related Bug description: SplFileObject->fgetcsv() segfaults when passing 0 as argument Description: See below. Reproduce code: --- fgetcsv(0); Actual result: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb65c56e0 (LWP 23504)] 0x083f49cc in php_fgetcsv_ex (stream=0xa54d3b4, delimiter=0xbf9f6228 "0b\237���Q\b��(\n\024", delimiter_len=1, enclosure=0xbf9f6224 "\"", enclosure_len=1, escape=0x6 , escape_len=1, buffer=0xa54d7a0 ", escape_len=1, buffer=0xa54d7a0 "http://bugs.php.net/?id=46647&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46647&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46647&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46647&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46647&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46647&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46647&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46647&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46647&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46647&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46647&r=support Expected behavior: http://bugs.php.net/fix.php?id=46647&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46647&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46647&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46647&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46647&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46647&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46647&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46647&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46647&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46647&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46647&r=mysqlcfg
#46646 [Asn]: serialize/unserialiaze og splfileinfo segfaults
ID: 46646
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type:SPL related
PHP Version: 6CVS-2008-11-22 (CVS)
Assigned To: colder
New Comment:
Another detail:
var_dump(unserialize(serialize(new splfileinfo(__FILE__;
object(SplFileInfo)#1 (1) {
[u"pathName":u"SplFileInfo":private]=>
NULL
}
[Sat Nov 22 15:43:48 2008] Script: '../bug.php'
/home/felipe/dev/php6/ext/spl/spl_directory.c(612) : Freeing
0x09BA8F78 (1 bytes), script=../bug.php
=== Total 1 memory leaks detected ===
Previous Comments:
[2008-11-22 17:35:17] [EMAIL PROTECTED]
Description:
splfileinfo serialization/unserialization segfaults in HEAD
Reproduce code:
---
print (string) unserialize(serialize(new splfileinfo(__FILE__)));
--
Edit this bug report at http://bugs.php.net/?id=46646&edit=1
#46646 [Opn->Asn]: serialize/unserialiaze og splfileinfo segfaults
ID: 46646 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type:SPL related PHP Version: 6CVS-2008-11-22 (CVS) -Assigned To: +Assigned To: colder Previous Comments: [2008-11-22 17:35:17] [EMAIL PROTECTED] Description: splfileinfo serialization/unserialization segfaults in HEAD Reproduce code: --- print (string) unserialize(serialize(new splfileinfo(__FILE__))); -- Edit this bug report at http://bugs.php.net/?id=46646&edit=1
#46646 [NEW]: serialize/unserialiaze og splfileinfo segfaults
From: [EMAIL PROTECTED] Operating system: PHP version: 6CVS-2008-11-22 (CVS) PHP Bug Type: SPL related Bug description: serialize/unserialiaze og splfileinfo segfaults Description: splfileinfo serialization/unserialization segfaults in HEAD Reproduce code: --- print (string) unserialize(serialize(new splfileinfo(__FILE__))); -- Edit bug report at http://bugs.php.net/?id=46646&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46646&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46646&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46646&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46646&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46646&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46646&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46646&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46646&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46646&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46646&r=support Expected behavior: http://bugs.php.net/fix.php?id=46646&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46646&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46646&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46646&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46646&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46646&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46646&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46646&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46646&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46646&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46646&r=mysqlcfg
#46645 [NEW]: gethostbyaddr() does not work with IPv6
From: carrerag at hotmail dot com Operating system: Windows XP PHP version: 5.2.7RC4 PHP Bug Type: Network related Bug description: gethostbyaddr() does not work with IPv6 Description: gethostbyaddr() function does not work properly. At least not on my Windows XP platform. This is with both versions 5.2.6 and with the latest snapshot 5.2.7RC4. This function does work properly in version 5.3alpha however, I cannot use that version due to other compatibility issues. Reproduce code: --- Expected result: Return "ipv6.he.net" Actual result: -- PHP Warning: gethostbyaddr() [function.gethostbyaddr]: Address is not in a.b.c.d form in C:\www\tests\saved\host.php on line 2 -- Edit bug report at http://bugs.php.net/?id=46645&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46645&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46645&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46645&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46645&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46645&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46645&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46645&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46645&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46645&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46645&r=support Expected behavior: http://bugs.php.net/fix.php?id=46645&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46645&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46645&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46645&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46645&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46645&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46645&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46645&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46645&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46645&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46645&r=mysqlcfg
#46641 [Bgs]: Timezone format inconsistencies between date() and DateTime::format()
ID: 46641 User updated by: cross+php at distal dot com Reported By: cross+php at distal dot com Status: Bogus Bug Type: Date/time related Operating System: * PHP Version: 5CVS, 6CVS (2008-11-21) New Comment: Okay. I can see this point, and thought something like that was involved, the transition through a timestamp. However, I would still like to know how to get 'T' (and 'e') to return what I expect. For example, I'd rather see 'EDT' than 'GMT-0500', and I still feel that '-05:00.0' instead of the expected long name may in fact be a [different] bug/error. Do you know how I can resolve this? It seems that setting the timezone of the DateTime causes the results of the 'T' and 'e' formatting parameter to work as expected. If I set the timezone to date_default_timezone_get, or assumedly anything else, it will return the format I expect for 'e' and 'T'. Is that the correct thing I should do to get the behaviour I expected? Thanks. Previous Comments: [2008-11-22 11:27:03] [EMAIL PROTECTED] 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 This is expected. Without converting to an integer with strtotime(), the DateTime object remembers which timezone it was created with. In this case the timezone it knows is "GMT-0500". If you use date(), this information is not available and it will use the default timezone. The following example shows this a bit better: [EMAIL PROTECTED]:/tmp$ cat bug46641.php format($outformat) . "\n"; ?> [EMAIL PROTECTED]:/tmp$ php bug46641.php Nov 19 2008 16:51:35 CET (Europe/Oslo,0,+0100,+01:00,CET,3600) Nov 19 2008 10:51:35 GMT-0500 (-05:00,0,-0500,-05:00,GMT-0500,-18000) [2008-11-21 17:46:13] cross+php at distal dot com Description: When using some of the timezone output format characters, notably "e" and "T", produce different results on a DateTime built from a string time and calling date() on the results of strtotime(). Reproduce code: --- format($outformat) . "\n"; ?> Expected result: Nov 19 2008 10:51:35 EST (America/New_York,0,-0500,-05:00,EST,-18000) Nov 19 2008 10:51:35 EST (America/New_York,0,-0500,-05:00,EST,-18000) Actual result: -- Nov 19 2008 10:51:35 EST (America/New_York,0,-0500,-05:00,EST,-18000) Nov 19 2008 10:51:35 GMT-0500 (-05:00,0,-0500,-05:00,GMT-0500,-18000) -- Edit this bug report at http://bugs.php.net/?id=46641&edit=1
#46644 [NEW]: https cURL failure
From: brian dot bream at comcast dot net Operating system: Solaris 10 08/07 x86 PHP version: 5.2.6 PHP Bug Type: cURL related Bug description: https cURL failure Description: Attempts to use cURL to an https site fails from within php, functions properly from the command line. cURL to an http site works in both locations. './configure' '--with-apxs2=/usr/apache2/bin/apxs' '--enable-dbase' '--with-libxml-dir=/usr/local' '--with-config-file-path=/etc/apache2' '--with-mysql=shared,/opt/csw/mysql5' '--with-mysqli=shared,/opt/csw/mysql5/bin/mysql_config' '--with-xpm-dir=/usr' '--with-gd' '--with-bz2=/usr/lib' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-zlib' '--enable-mbstring' '--enable-calendar' '--enable-bcmath' '--enable-ftp' '--enable-exif' '--with-openssl=shared,/usr/sfw' '--with-curl=/usr/local/bin/' '--with-pdo-mysql=shared,/opt/csw/mysql5/' phpinfo at http://preferredsystems.com/phpinfo.php Expected result: A successful https connection to any site. Actual result: -- A curl test to an https site returns: Errors: 35 error:80089077:lib(128):func(137):reason(119) This test was run at http://preferredsystems.com/curl_test.php making a call to https:secure.authorize.net >From the command line it works properly bash-3.00# curl -v https://secure.authorize.net * About to connect() to secure.authorize.net port 443 (#0) * Trying 64.94.118.32... connected * Connected to secure.authorize.net (64.94.118.32) port 443 (#0) * successfully set certificate verify locations: * CAfile: /var/tmp/cacert.pem CApath: none * SSLv2, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS handshake, Server finished (14): . -- Edit bug report at http://bugs.php.net/?id=46644&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46644&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46644&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46644&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46644&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46644&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46644&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46644&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46644&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46644&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46644&r=support Expected behavior: http://bugs.php.net/fix.php?id=46644&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46644&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46644&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46644&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46644&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46644&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46644&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46644&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46644&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46644&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46644&r=mysqlcfg
#46643 [NEW]: plz upgrade pcre to 7.8~
From: paulgao at yeah dot net Operating system: Linux PHP version: 5.2.7RC4 PHP Bug Type: PCRE related Bug description: plz upgrade pcre to 7.8~ Description: plz upgrade pcre to 7.8, 7.6 is old old old... -- Edit bug report at http://bugs.php.net/?id=46643&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46643&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46643&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46643&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46643&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46643&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46643&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46643&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46643&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46643&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46643&r=support Expected behavior: http://bugs.php.net/fix.php?id=46643&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46643&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46643&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46643&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46643&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46643&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46643&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46643&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46643&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46643&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46643&r=mysqlcfg
#46641 [Ver->Bgs]: Timezone format inconsistencies between date() and DateTime::format()
ID: 46641 Updated by: [EMAIL PROTECTED] Reported By: cross+php at distal dot com -Status: Verified +Status: Bogus Bug Type: Date/time related Operating System: * PHP Version: 5CVS, 6CVS (2008-11-21) 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 This is expected. Without converting to an integer with strtotime(), the DateTime object remembers which timezone it was created with. In this case the timezone it knows is "GMT-0500". If you use date(), this information is not available and it will use the default timezone. The following example shows this a bit better: [EMAIL PROTECTED]:/tmp$ cat bug46641.php format($outformat) . "\n"; ?> [EMAIL PROTECTED]:/tmp$ php bug46641.php Nov 19 2008 16:51:35 CET (Europe/Oslo,0,+0100,+01:00,CET,3600) Nov 19 2008 10:51:35 GMT-0500 (-05:00,0,-0500,-05:00,GMT-0500,-18000) Previous Comments: [2008-11-21 17:46:13] cross+php at distal dot com Description: When using some of the timezone output format characters, notably "e" and "T", produce different results on a DateTime built from a string time and calling date() on the results of strtotime(). Reproduce code: --- format($outformat) . "\n"; ?> Expected result: Nov 19 2008 10:51:35 EST (America/New_York,0,-0500,-05:00,EST,-18000) Nov 19 2008 10:51:35 EST (America/New_York,0,-0500,-05:00,EST,-18000) Actual result: -- Nov 19 2008 10:51:35 EST (America/New_York,0,-0500,-05:00,EST,-18000) Nov 19 2008 10:51:35 GMT-0500 (-05:00,0,-0500,-05:00,GMT-0500,-18000) -- Edit this bug report at http://bugs.php.net/?id=46641&edit=1
#46636 [Asn]: feof() blocking on non-blocking socket
ID: 46636
Updated by: [EMAIL PROTECTED]
Reported By: aragon at phat dot za dot net
Status: Assigned
Bug Type: Streams related
Operating System: FreeBSD 7.0-STABLE
PHP Version: 5.2.7RC4
-Assigned To: lbarnaud
+Assigned To: dsp
New Comment:
David, please check when checking #46049
Previous Comments:
[2008-11-21 13:31:18] [EMAIL PROTECTED]
I will, but it seems related to this one:
http://bugs.php.net/bug.php?id=46049
[2008-11-21 08:30:29] [EMAIL PROTECTED]
Arnaud, can you take a look please?
http://tinyurl.com/6g42xf
[2008-11-21 02:59:04] aragon at phat dot za dot net
Sorry, I pasted misleading reproduce code. It should be:
0) {
echo $i.':'.(time()-$start).chr(10);
if (feof($socket)) break;
echo $i++.':'.(time()-$start).chr(10);
switch ($state) {
case 1:
fwrite($socket, 'GET /blog HTTP/1.0' .
chr(13).chr(10).chr(13).chr(10));
$state = 2; break;
case 2:
if (fread($socket, 8192)) echo 'ooo'.chr(10); break;
}
}
}
echo (time()-$start).chr(10);
?>
[2008-11-21 02:56:54] aragon at phat dot za dot net
Description:
There was a change since 5.2.6 release that is causing feof() to block
when testing a non-blocking socket for EOF. It happens if the socket
has no data waiting in its buffer and is open.
If I compare 5.2.6 and 5.2.7 code it looks like
main/streams/streams.c:642:
if (!stream->eof && PHP_STREAM_OPTION_RETURN_ERR ==
php_stream_set_option(stream,
PHP_STREAM_OPTION_CHECK_LIVENESS,
-1, NULL)) {
stream->eof = 1;
}
In 5.2.6 php_stream_set_option is called with a value of 0, not -1.
Reproduce code:
---
0) {
echo $i.':'.time().chr(10);
if (feof($socket)) break;
echo $i++.':'.time().chr(10);
switch ($state) {
case 1:
fwrite($socket, 'GET /blog HTTP/1.0' .
chr(13).chr(10).chr(13).chr(10));
$state = 2; break;
case 2:
if (fread($socket, 8192)) echo 'ooo'.chr(10); break;
}
}
}
echo time().chr(10);
?>
Expected result:
1:0
1:0
1:0
2:0
2:0
2:0
ooo
3:0
3:0
0
Actual result:
--
1:0
1:0
1:5
2:5
2:5
2:5
ooo
3:5
3:5
5
--
Edit this bug report at http://bugs.php.net/?id=46636&edit=1
