#47395 [Com]: session expiration date misformatted
ID: 47395 Comment by: tdtwisteruk at hotmail dot com Reported By: tdtwisteruk at hotmal dot com Status: Feedback Bug Type: Session related Operating System: linux PHP Version: 5.2CVS-2009-02-15 (CVS) New Comment: No the actual test was done in php 5.2.8. Previous Comments: [2009-02-15 21:44:19] scott...@php.net Pretty sure I fixed this in December, did you really test a CVS snapshot? http://cvs.php.net/viewvc.cgi/php-src/ext/session/session.c?r1=1.417.2.8.2.44r2=1.417.2.8.2.45pathrev=PHP_5_2view=patch [2009-02-15 19:51:42] tdtwisteuk at hotmail dot com It appears that the browser behavior I mention earlyer was caused by domain=localhost attribute, even though I run the page from localhost. Anyway the cookie expirtion date is different from the session expiration. To fix this change line 1119 in ext/session/session.c to date_fmt = php_format_date(D, d-M-Y H:i:s T, sizeof(D, d-M-Y H:i:s T)-1, t, 0 TSRMLS_CC); [2009-02-15 15:18:44] tdtwisteuk at hotmail dot com The problem appear to be related with the bugfix #31583. quoting NEWS Fixed bug #31583 (php_std_date() uses short day names in non-y2k_compliance mode). (mike at php dot net) The php_std_date function is used to form the session date instead of the strcpy_gmt() in the session.c file [2009-02-15 14:58:33] tdtwisteruk at hotmal dot com Description: The problem appear to be the wrong formating of the expiration date that cause meny browsers to ignore the session cookie. I think I have manage to track the bug. It appears to be on the file /ext/session/session.c line 1119. I am currently working on a patch. It should be trivial. Reproduce code: --- session_set_cookie_params( $lifetime, $path, $domain, $isSecure, $httponly ); session_start(); Expected result: frontend=90b770550657dbe845656805a1e9bfe0; expires=Sun, 15-Feb-09 15:53:53 GMT; path=/magento; domain=localhost; HttpOnly Actual result: -- frontend=90b770550657dbe845656805a1e9bfe0; expires=Sunday, 15-Feb-09 15:53:53 GMT; path=/magento; domain=localhost; HttpOnly -- Edit this bug report at http://bugs.php.net/?id=47395edit=1
#47395 [Com]: session expiration date misformatted
ID: 47395 Comment by: tdtwisteruk at hotmail dot com Reported By: tdtwisteruk at hotmal dot com Status: Feedback Bug Type: Session related Operating System: linux PHP Version: 5.2CVS-2009-02-15 (CVS) New Comment: Yes you are actually right. It is fixed on the csv repository. Sorry I bother you. Next time I will check better. Previous Comments: [2009-02-16 09:00:40] tdtwisteruk at hotmail dot com No the actual test was done in php 5.2.8. [2009-02-15 21:44:19] scott...@php.net Pretty sure I fixed this in December, did you really test a CVS snapshot? http://cvs.php.net/viewvc.cgi/php-src/ext/session/session.c?r1=1.417.2.8.2.44r2=1.417.2.8.2.45pathrev=PHP_5_2view=patch [2009-02-15 19:51:42] tdtwisteuk at hotmail dot com It appears that the browser behavior I mention earlyer was caused by domain=localhost attribute, even though I run the page from localhost. Anyway the cookie expirtion date is different from the session expiration. To fix this change line 1119 in ext/session/session.c to date_fmt = php_format_date(D, d-M-Y H:i:s T, sizeof(D, d-M-Y H:i:s T)-1, t, 0 TSRMLS_CC); [2009-02-15 15:18:44] tdtwisteuk at hotmail dot com The problem appear to be related with the bugfix #31583. quoting NEWS Fixed bug #31583 (php_std_date() uses short day names in non-y2k_compliance mode). (mike at php dot net) The php_std_date function is used to form the session date instead of the strcpy_gmt() in the session.c file [2009-02-15 14:58:33] tdtwisteruk at hotmal dot com Description: The problem appear to be the wrong formating of the expiration date that cause meny browsers to ignore the session cookie. I think I have manage to track the bug. It appears to be on the file /ext/session/session.c line 1119. I am currently working on a patch. It should be trivial. Reproduce code: --- session_set_cookie_params( $lifetime, $path, $domain, $isSecure, $httponly ); session_start(); Expected result: frontend=90b770550657dbe845656805a1e9bfe0; expires=Sun, 15-Feb-09 15:53:53 GMT; path=/magento; domain=localhost; HttpOnly Actual result: -- frontend=90b770550657dbe845656805a1e9bfe0; expires=Sunday, 15-Feb-09 15:53:53 GMT; path=/magento; domain=localhost; HttpOnly -- Edit this bug report at http://bugs.php.net/?id=47395edit=1
#45704 [Com]: $exception-getCode() always return 0x80020009 even when it shouldn't
ID: 45704
Comment by: tceverling at yahoo dot co dot uk
Reported By: tceverling at yahoo dot co dot uk
Status: Open
Bug Type: COM related
Operating System: Windows XP SP2
PHP Version: 5.2.6
New Comment:
This bug is still present in Apache/2.2.10 (Win32) PHP/5.2.8, Windows
XP SP3.
We are still unable to use the codes provided by the thrown exceptions
to provide alternative paths or give meaningful messages either to the
user or to an error log.
Previous Comments:
[2008-08-04 07:30:18] tceverling at yahoo dot co dot uk
Description:
When a COM object throws an exception, the getCode() always return
0x80020009 even when it should be some other value.
This is reproducible with Scripting.FileSystemObject,
Scripting.Dictionary and Autodesk.MgSdfToolkit.
Reproduce code:
---
echo 'For Scripting.FileSystemObject.';
try {
$fso = new COM(Scripting.FileSystemObject);
$f = $fso-GetFile(c:\\does not exist.txt);
}
catch (Exception $e) {
//print_r($e);
echo dechex($e-getCode());
}
echo 'For Scripting.Dictionary.';
try {
$d = new COM(Scripting.Dictionary);
$d-Remove(b);
}
catch (Exception $e) {
//print_r($e);
echo dechex($e-getCode());
}
Expected result:
For 'Scripting.FileSystemObject': 800A0035
For 'Scripting.Dictionary': 800A802B
Actual result:
--
For 'Scripting.FileSystemObject': 80020009
For 'Scripting.Dictionary': 80020009
--
Edit this bug report at http://bugs.php.net/?id=45704edit=1
#47381 [Bgs]: Some expressions (of classes) don't behave logical
ID: 47381
User updated by: t dot nickl at exse dot de
Reported By: t dot nickl at exse dot de
Status: Bogus
Bug Type: *General Issues
Operating System: Ubuntu 8.10
PHP Version: 6CVS-2009-02-13 (snap)
New Comment:
Thank you!
Previous Comments:
[2009-02-13 21:11:32] fel...@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
[2009-02-13 13:34:46] t dot nickl at exse dot de
Description:
class A
{
public function getName()
{
return(a);
}
}
//Issue 1:
//This produces syntax error, unexpected T_OBJECT_OPERATOR:
echo new A()-getName();
//This works:
$_= new A();
echo $_-getName();
//Issue 2:
//This produces Can't use function return value in write context:
$b= a;
var_dump(empty(trim($a)));
//This works:
$b= a;
$_= trim($a);
var_dump(empty($_));
//In php, I must assign an expression to a variable first
// before being able to use it at some points? Why?
--
Edit this bug report at http://bugs.php.net/?id=47381edit=1
#47402 [NEW]: call_user_func propagating the scope while it didn't in 5_2
From: col...@php.net
Operating system:
PHP version: 5.3.0beta1
PHP Bug Type: Scripting Engine problem
Bug description: call_user_func propagating the scope while it didn't in 5_2
Description:
Depending on the context and the callback, call_user_func didn't propagate
$this in 5_2. It now does in 5_3. Not sure which one is more correct, but
there is definitely a potential BC break here.
Reproduce code:
---
?php
class A {
public function test() {
B::foo();
call_user_func(array(B, foo));
}
}
class B extends A {
public function foo() {
var_dump($this);
}
}
$b = new B; $b-test();
?
Expected result:
// 5_2's output
object(B)#1 (0) {
}
NULL
Actual result:
--
// 5_3's output
object(B)#1 (0) {
}
object(B)#1 (0) {
}
--
Edit bug report at http://bugs.php.net/?id=47402edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47402r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47402r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47402r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47402r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47402r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47402r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47402r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47402r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47402r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47402r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47402r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47402r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47402r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47402r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47402r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47402r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47402r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47402r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47402r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47402r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47402r=mysqlcfg
#47402 [Opn-Asn]: call_user_func propagating the scope while it didn't in 5_2
ID: 47402
Updated by: col...@php.net
Reported By: col...@php.net
-Status: Open
+Status: Assigned
Bug Type:Scripting Engine problem
PHP Version: 5.3.0beta1
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2009-02-16 10:33:00] col...@php.net
Description:
Depending on the context and the callback, call_user_func didn't
propagate $this in 5_2. It now does in 5_3. Not sure which one is more
correct, but there is definitely a potential BC break here.
Reproduce code:
---
?php
class A {
public function test() {
B::foo();
call_user_func(array(B, foo));
}
}
class B extends A {
public function foo() {
var_dump($this);
}
}
$b = new B; $b-test();
?
Expected result:
// 5_2's output
object(B)#1 (0) {
}
NULL
Actual result:
--
// 5_3's output
object(B)#1 (0) {
}
object(B)#1 (0) {
}
--
Edit this bug report at http://bugs.php.net/?id=47402edit=1
#47395 [Fbk-Bgs]: session expiration date misformatted
ID: 47395 Updated by: fel...@php.net Reported By: tdtwisteruk at hotmal dot com -Status: Feedback +Status: Bogus Bug Type: Session related Operating System: linux PHP Version: 5.2CVS-2009-02-15 (CVS) New Comment: . Previous Comments: [2009-02-16 09:11:00] tdtwisteruk at hotmail dot com Yes you are actually right. It is fixed on the csv repository. Sorry I bother you. Next time I will check better. [2009-02-16 09:00:40] tdtwisteruk at hotmail dot com No the actual test was done in php 5.2.8. [2009-02-15 21:44:19] scott...@php.net Pretty sure I fixed this in December, did you really test a CVS snapshot? http://cvs.php.net/viewvc.cgi/php-src/ext/session/session.c?r1=1.417.2.8.2.44r2=1.417.2.8.2.45pathrev=PHP_5_2view=patch [2009-02-15 19:51:42] tdtwisteuk at hotmail dot com It appears that the browser behavior I mention earlyer was caused by domain=localhost attribute, even though I run the page from localhost. Anyway the cookie expirtion date is different from the session expiration. To fix this change line 1119 in ext/session/session.c to date_fmt = php_format_date(D, d-M-Y H:i:s T, sizeof(D, d-M-Y H:i:s T)-1, t, 0 TSRMLS_CC); [2009-02-15 15:18:44] tdtwisteuk at hotmail dot com The problem appear to be related with the bugfix #31583. quoting NEWS Fixed bug #31583 (php_std_date() uses short day names in non-y2k_compliance mode). (mike at php dot net) The php_std_date function is used to form the session date instead of the strcpy_gmt() in the session.c file 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/47395 -- Edit this bug report at http://bugs.php.net/?id=47395edit=1
#47403 [NEW]: preg_replace function
From: jignasha_86 at yahoo dot co dot in Operating system: All PHP version: 5.2.9RC2 PHP Bug Type: Regexps related Bug description: preg_replace function Description: In preg_replace function,you are replacing one string to other if replacing string contains $ sign in it,then preg_replace suppress $ sign and 2 charcaters after that $ sign This happens in all PHP 5 versions Reproduce code: --- $pattern[] = /_BASEURL_/; //$pattern[] = /_BASELOGIN_/; $pattern[] = /_SENDERNAME_/; $pattern[] = /_ISSUETITLE_/; $pattern[] = /\'\'/; $replacement[] = BASEURL; $replacement[] = $msg_sendername; $replacement[] = $istitle; $replacement[] = '; $msg_body = preg_replace($pattern, $replacement, $msg_body); if $istitle = This is $888 ruppes; Then It will replace it with This is 8 rupees -- Edit bug report at http://bugs.php.net/?id=47403edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47403r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47403r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47403r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47403r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47403r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47403r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47403r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47403r=needscript Try newer version: http://bugs.php.net/fix.php?id=47403r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47403r=support Expected behavior: http://bugs.php.net/fix.php?id=47403r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47403r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47403r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47403r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47403r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47403r=dst IIS Stability: http://bugs.php.net/fix.php?id=47403r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47403r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47403r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47403r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47403r=mysqlcfg
#47405 [NEW]: error reports wrong file/line
From: dennis at born05 dot nl
Operating system: Fedora Core 6
PHP version: 5.2CVS-2009-02-16 (snap)
PHP Bug Type: Class/Object related
Bug description: error reports wrong file/line
Description:
When creating an instance of a class which tries to access a non-
existent parent in the class definition it throws an error on the
file/line where the class is instantiated while i would assume it
should be thrown where the error occurs, ie where the class tries to
access its non-existent parent.
Reproduce code:
---
?php
class myclass
{
public $foo = parent::BAR;
}
new myclass();
?
Expected result:
Fatal error: Cannot access parent:: when current class scope has no
parent in /my/file.php on line 4 (the line which refers to the non-
existent parent)
Actual result:
--
Fatal error: Cannot access parent:: when current class scope has no
parent in /var/www/html/swish/trunk/bug.php on line 6 (the line which
creates the instance of myclass)
--
Edit bug report at http://bugs.php.net/?id=47405edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47405r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47405r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47405r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47405r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47405r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47405r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47405r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47405r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47405r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47405r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47405r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47405r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47405r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47405r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47405r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47405r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47405r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47405r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47405r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47405r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47405r=mysqlcfg
#47404 [NEW]: mysql_fetch_array
From: jignasha_86 at yahoo dot co dot in Operating system: All PHP version: 5.2.9RC2 PHP Bug Type: MySQL related Bug description: mysql_fetch_array Description: When we allow in data from user, that will inserted correctly in database,Even running query manually will give correct results and fetching data, but when we do it with mysql_fetch_array function, It will give blank data in between brackets Reproduce code: --- If $data = This is testing data; Insert this string as one field of database It will get inserted correctly,when we fetch using any MySQL feching function like mysql_fetch_array or mysql_fetch_row, it will be like This is data; Eliminating and data in between that brackets -- Edit bug report at http://bugs.php.net/?id=47404edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47404r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47404r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47404r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47404r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47404r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47404r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47404r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47404r=needscript Try newer version: http://bugs.php.net/fix.php?id=47404r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47404r=support Expected behavior: http://bugs.php.net/fix.php?id=47404r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47404r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47404r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47404r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47404r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47404r=dst IIS Stability: http://bugs.php.net/fix.php?id=47404r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47404r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47404r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47404r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47404r=mysqlcfg
#47404 [Opn-Bgs]: mysql_fetch_array
ID: 47404 Updated by: der...@php.net Reported By: jignasha_86 at yahoo dot co dot in -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: All PHP Version: 5.2.9RC2 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. Tip: Do a view source in your browser. Previous Comments: [2009-02-16 11:49:15] jignasha_86 at yahoo dot co dot in Description: When we allow in data from user, that will inserted correctly in database,Even running query manually will give correct results and fetching data, but when we do it with mysql_fetch_array function, It will give blank data in between brackets Reproduce code: --- If $data = This is testing data; Insert this string as one field of database It will get inserted correctly,when we fetch using any MySQL feching function like mysql_fetch_array or mysql_fetch_row, it will be like This is data; Eliminating and data in between that brackets -- Edit this bug report at http://bugs.php.net/?id=47404edit=1
#46156 [Asn]: Infinite recursion in class destructor causes crash
ID: 46156
Updated by: ka...@php.net
Reported By: ka...@php.net
Status: Assigned
Bug Type: Reproducible crash
Operating System: *
PHP Version: 5CVS-2008-11-11
Assigned To: dmitry
New Comment:
Heres another one with __call():
?php
class Test
{
public function __call($call, Array $args)
{
call_user_func_array(Array($this, $call), $args);
}
}
$test = new Test;
$test-crash();
?
Previous Comments:
[2008-12-05 07:28:28] ka...@php.net
I've discovered one more crash and reported here of the same type:
http://bugs.php.net/bug.php?id=46754
[2008-09-23 10:00:25] ka...@php.net
Description:
Creating a new instance of the same class in a class destructor which
causes infinite recursion will cause PHP to crash, instead of throwing a
memory_limit error.
Dmitry told me to report this so it wouldn't be forgotten.
Reproduce code:
---
?php
class Crash
{
public function __destruct()
{
new self;
}
}
new Crash;
?
Expected result:
memory_limit error
Actual result:
--
Crash
--
Edit this bug report at http://bugs.php.net/?id=46156edit=1
#47407 [NEW]: There can be only one PDO (derived) instance with ATTR_PERSISTENT
From: dennis at born05 dot nl
Operating system: Fedora Core 6
PHP version: 5.2CVS-2009-02-16 (snap)
PHP Bug Type: PDO related
Bug description: There can be only one PDO (derived) instance with
ATTR_PERSISTENT
Description:
When you create 2 or more instances of PDO (or derived) with
ATTR_PERSISTENT you end up with several references to only one
object.
Reproduce code:
---
?php
class MyPDO extends PDO {}
$bar = new PDO(sqlite::memory:, null, null, array(PDO::ATTR_PERSISTENT
= true));
$baz = new MyPDO(sqlite::memory:, null, null, array(PDO::ATTR_PERSISTENT
= true));
var_dump ($bar);
var_dump ($baz);
?
Expected result:
object(PDO)#1 (0) {
}
object(MyPDO)#2 (0) {
}
Actual result:
--
object(MyPDO)#1 (0) {
}
object(MyPDO)#2 (0) {
}
--
Edit bug report at http://bugs.php.net/?id=47407edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47407r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47407r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47407r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47407r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47407r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47407r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47407r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47407r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47407r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47407r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47407r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47407r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47407r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47407r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47407r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47407r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47407r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47407r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47407r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47407r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47407r=mysqlcfg
#47370 [Bgs-Opn]: array_unique has backward compatibility problem, and SORT_REGULAR is confusing
ID: 47370
Updated by: moriyo...@php.net
Reported By: for-bugs at hnw dot jp
-Status: Bogus
+Status: Open
Bug Type: Arrays related
Operating System: any
PHP Version: 5.2.9RC1
Previous Comments:
[2009-02-14 08:28:18] for-bugs at hnw dot jp
OK, you think comparing elements as string is harmful, doesn't you?
Then, how about array_diff() or array_intersect()? They compare array
elements with string representation. Isn't it harmful?
[2009-02-14 08:22:26] moriyo...@php.net
This was not discussed, and thus no bogus thing.
[2009-02-13 22:27:35] and...@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
The slight BC breakage is negligible compared to the benefits of
getting it to work properly.
[2009-02-13 01:53:09] for-bugs at hnw dot jp
Thank you so much. The snapshot returns same result to PHP 5.2.8 with
reproduce code. Such as:
array(2) {
[0]=
int(0)
[1]=
string(0)
}
array(2) {
[0]=
string(0)
[1]=
string(1) 0
}
[2009-02-12 18:58:34] moriyo...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
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/47370
--
Edit this bug report at http://bugs.php.net/?id=47370edit=1
#47403 [Opn-Bgs]: preg_replace function
ID: 47403 Updated by: scott...@php.net Reported By: jignasha_86 at yahoo dot co dot in -Status: Open +Status: Bogus Bug Type: PCRE related Operating System: All PHP Version: 5.2.9RC2 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. You have a replacement back reference and that only accepts 2 numbers, $0 - $99. So $88 - '' and hence why you see 8. If you escape the replacement correctly then it will work. Previous Comments: [2009-02-16 11:40:09] jignasha_86 at yahoo dot co dot in Description: In preg_replace function,you are replacing one string to other if replacing string contains $ sign in it,then preg_replace suppress $ sign and 2 charcaters after that $ sign This happens in all PHP 5 versions Reproduce code: --- $pattern[] = /_BASEURL_/; //$pattern[] = /_BASELOGIN_/; $pattern[] = /_SENDERNAME_/; $pattern[] = /_ISSUETITLE_/; $pattern[] = /\'\'/; $replacement[] = BASEURL; $replacement[] = $msg_sendername; $replacement[] = $istitle; $replacement[] = '; $msg_body = preg_replace($pattern, $replacement, $msg_body); if $istitle = This is $888 ruppes; Then It will replace it with This is 8 rupees -- Edit this bug report at http://bugs.php.net/?id=47403edit=1
#47366 [Opn-Csd]: mb_convert_encoding() converts some symbols incorrectly from EUC-JP to UTF-8
ID: 47366 User updated by: max at injapan dot ru Reported By: max at injapan dot ru -Status: Open +Status: Closed Bug Type: mbstring related Operating System: CentOS 5.2 PHP Version: 5.3CVS-2009-02-12 (snap) New Comment: Problem solved with encoding EUCJP-WIN instead of EUC-JP. Previous Comments: [2009-02-12 10:06:17] max at injapan dot ru Text in Expected result field is messed a little: of course, expected output is just one character U+2161. [2009-02-12 10:04:11] max at injapan dot ru Description: mb_convert_encoding converts symbols \xAD\xB5-\xAD\xBF incorrectly from EUC-JP to UTF-8. It's possible that some other symbols converted incorrectly too, but I have no possibility to check it to full extent. Unicode has corresponding codepoints, i.e. U+2161 for #8545;. Majority of EUC-JP texts is converted mormally. Reproduce code: --- echo mb_convert_encoding(\xAD\xB6, UTF-8, EUC-JP); Expected result: string «#8545;» (U+2161) printed to STDOUT Actual result: -- string «?» printed to STDOUT -- Edit this bug report at http://bugs.php.net/?id=47366edit=1
#47397 [Com]: php://stdout gives odd behavior under CGI/Apache
ID: 47397
Comment by: shaunspiller at gmail dot com
Reported By: shaunspiller at gmail dot com
Status: Feedback
Bug Type: Output Control
Operating System: Any?
PHP Version: 5.2.9RC2
New Comment:
I'm using php-5.2.9RC2-Win32-VC6-x86.zip (last modified:
2009-Feb-12).
The STDOUT constant is only defined for CLI. The documentation isn't
clear on what the correct behavior of the stdout stream should be under
other interfaces.
Previous Comments:
[2009-02-15 23:15:53] j...@php.net
1. Exactly what PHP version are you using here?
2. What if you don't open another stdout stream but use the STDOUT
constant, does it work better..?
For more info: http://www.php.net/wrappers.php
[2009-02-15 19:16:22] shaunspiller at gmail dot com
Description:
Hi!
I think this might be a bug. I was writing some code that used output
buffering, but which also bypassed it by writing directly to stdout.
I've done before it under CLI but the results I got under CGI and as an
Apache module were a bit strange:
Example 1:
--
?php
echo 1. echo, before output bufferingbr\n;
ob_start();
echo 2. echo, during output bufferingbr\n;
flush();
/* in theory, this line will be output immediately while 2 4 will be
held back until ob_end_flush() */
$stdout = fopen('php://stdout', 'w');
fwrite($stdout, 3. fwrite to stdout, during output bufferingbr\n);
echo 4. echo, during output bufferingbr\n;
ob_end_flush();
echo 5. echo, after output bufferingbr\n;
?
Result:
---
I'm not expert on how PHP communicates with its various output
mechanisms. These are just my observations from testing this code:
* Under CLI, this example works, and the displayed order is 1, 3, 2, 4,
5.
* As an Apache module, no. 3 is never output, no matter how much I try
to flush it through. (Maybe that is the intended behavior, since the
STDOUT constant is not defined.)
* Under CGI, no. 3 is never output **unless** at least 1 previous
byte has been flushed (provided by the echo()s and flush() call, above).
In that case, the displayed order is 1, 3, 2, 4, 5 again. I'm not sure
if it's supposed to work or not, but the inconsistency seems wrong.
* (In all cases, the fopen call returns a valid stream.)
Example 2:
--
?php
header('Cache-Control: no-cache');
$stdout = fopen('php://stdout', 'w');
fwrite($stdout, Location: http://www.php.net/\r\n;);
?
Result:
---
This is even stranger. Under CGI, if at least one call to header() has
been made and no other data has yet been flushed, writing to stdout puts
data directly into the HTTP response. In this case I've used a complete
valid header so it can be tested from a browser.
It's also possible to write complete garbage into the headers,
bypassing the header() function's restrictions (this is best observed
via telnet), and this is what was unintentionally happening when I first
encountered this.
Expected result:
It would be nice if stdout would always work, and always bypass output
buffering. Otherwise, it should at least be consistent within each
interface.
--
Edit this bug report at http://bugs.php.net/?id=47397edit=1
#47402 [Asn-Fbk]: call_user_func propagating the scope while it didn't in 5_2
ID: 47402
Updated by: dmi...@php.net
Reported By: col...@php.net
-Status: Assigned
+Status: Feedback
Bug Type:Scripting Engine problem
PHP Version: 5.3.0beta1
Assigned To: dmitry
New Comment:
This is not a bug, but just an illustration of
is_callable/call_user_func mess which was fixed in 5.3 comparing to 5.2.
The following extended example illustrates inconsistent behaviour of
5.2. Using call_user_func() it passes $this in one case and not in the
other, however direct call passes %this in both cases.
?php
class A {
public function test() {
B::foo();
call_user_func(array(B,foo));
}
public function bar() {
var_dump($this);
}
}
class B extends A {
public function foo() {
var_dump($this);
}
public function test2() {
A::bar();
call_user_func(array(A,bar));
}
}
$b = new B; $b-test(); $b-test2();
?
PHP-5.2
---
object(B)#1 (0) {
}
NULL
object(B)#1 (0) {
}
object(B)#1 (0) {
}
PHP-5.3
---
object(B)#1 (0) {
}
object(B)#1 (0) {
}
object(B)#1 (0) {
}
object(B)#1 (0) {
}
Previous Comments:
[2009-02-16 10:33:00] col...@php.net
Description:
Depending on the context and the callback, call_user_func didn't
propagate $this in 5_2. It now does in 5_3. Not sure which one is more
correct, but there is definitely a potential BC break here.
Reproduce code:
---
?php
class A {
public function test() {
B::foo();
call_user_func(array(B, foo));
}
}
class B extends A {
public function foo() {
var_dump($this);
}
}
$b = new B; $b-test();
?
Expected result:
// 5_2's output
object(B)#1 (0) {
}
NULL
Actual result:
--
// 5_3's output
object(B)#1 (0) {
}
object(B)#1 (0) {
}
--
Edit this bug report at http://bugs.php.net/?id=47402edit=1
#47230 [Ver-Ctl]: Bug with gcc Optimizer on Sparc systems
ID: 47230 Updated by: scott...@php.net Reported By: lneve at mail dot nih dot gov -Status: Verified +Status: Critical Bug Type: Reproducible crash Operating System: Solaris 10 (completely patched) -PHP Version: 5.3.0alpha3 +PHP Version: 5.3.0-beta2-dev Previous Comments: [2009-01-28 17:16:25] scott...@php.net This is a gcc optimizer bug, if you do CFLAGS=-O0 prior to compiling it you don't get a problem. I've been told SunCC works fine. [2009-01-28 13:40:16] lneve at mail dot nih dot gov If I build with --disable-phar it builds successfully but make test fails with: -bash-3.00# make test Build complete. Don't forget to run 'make test'. Bus Error - core dumped *** Error code 138 (ignored) The following command caused the error: if test ! -z test -x ; then \ TEST_PHP_EXECUTABLE= \ TEST_PHP_SRCDIR=/opt/php-5.3.0alpha3 \ CC=gcc \ -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' /opt/php-5.3.0alpha3/run-tests.php -d extension_dir=modules/ ` if test x != x; then for i in ; do . $i; /opt/php-5.3.0alpha3/build/shtool echo -n -- -d extension=$dlname; done; fi; if test x != x; then for i in ; do . $i; /opt/php-5.3.0alpha3/build/shtool echo -n -- -d zend_extension=/opt/php-5.3.0alpha3/modules/$dlname; done; fi` tests/; \ elif test ! -z sapi/cli/php test -x sapi/cli/php; then \ INI_FILE=`/opt/php-5.3.0alpha3/sapi/cli/php -d 'display_errors=stderr' -r 'echo php_ini_loaded_file();' 2 /dev/null`; \ if test $INI_FILE; then \ egrep -v '^(zend_)?extension(_debug)?(_ts)?[\t\ ]*=' $INI_FILE /opt/php-5.3.0alpha3/tmp-php.ini; \ else \ echo /opt/php-5.3.0alpha3/tmp-php.ini; \ fi; \ INI_SCANNED_PATH=`/opt/php-5.3.0alpha3/sapi/cli/php -d 'display_errors=stderr' -r '$a = explode(,\n, trim(php_ini_scanned_files())); echo $a[0];' 2 /dev/null`; \ if test $INI_SCANNED_PATH; then \ INI_SCANNED_PATH=`/opt/php-5.3.0alpha3/build/shtool path -d $INI_SCANNED_PATH`; \ egrep -h -v '^(zend_)?extension(_debug)?(_ts)?[\t\ ]*=' $INI_SCANNED_PATH/*.ini /opt/php-5.3.0alpha3/tmp-php.ini; \ fi; \ TEST_PHP_EXECUTABLE=/opt/php-5.3.0alpha3/sapi/cli/php \ TEST_PHP_SRCDIR=/opt/php-5.3.0alpha3 \ CC=gcc \ /opt/php-5.3.0alpha3/sapi/cli/php -n -c /opt/php-5.3.0alpha3/tmp-php.ini -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' /opt/php-5.3.0alpha3/run-tests.php -n -c /opt/php-5.3.0alpha3/tmp-php.ini -d extension_dir=/opt/php-5.3.0alpha3/modules/ ` if test x != x; then for i in ; do . $i; /opt/php-5.3.0alpha3/build/shtool echo -n -- -d extension=$dlname; done; fi; if test x != x; then for i in ; do . $i; /opt/php-5.3.0alpha3/build/shtool echo -n -- -d zend_extension=/opt/php-5.3.0alpha3/modules/$dlname; done; fi` ; \ else \ echo ERROR: Cannot run tests without CLI sapi.; \ fi [2009-01-28 13:32:49] lneve at mail dot nih dot gov It's a sparc system. Is there a workaround since I don't need phar? If I add --disable-phar it builds successfully, but experiences a bus error during make test. [2009-01-28 13:28:08] scott...@php.net What sort of processor do you have? There is a problem with sparc and ppc processors and phar. [2009-01-28 13:17:46] lneve at mail dot nih dot gov Description: Here is the relevant part of the make output: -bash-3.00# gmake Generating phar.php Bus Error - core dumped gmake: *** [ext/phar/phar.php] Error 138 Someone reported a similar bug in the previous release on the Irix OS (bug #46074). I use the vanilla Solaris gcc compiler (version 3.4.3). Here are my configure options: ./configure --with-pgsql=/opt/postgres/8.3-community --with-mysql=/opt/mysql --with-mysqli=/opt/mysql/bin/mysql_config --with-apxs2=/opt/httpd/bin/apxs --with-config-file-path=/etc --with-libxml-dir=/usr/lib --with-zlib-dir=/usr/lib --enable-zip --enable-mbstring --with-gd --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-xpm-dir=/usr/lib --with-freetype-dir=/usr/sfw --with-pdo-mysql=/opt/mysql --with-pdo-pgsql=/opt/pgsql --with-gettext=/usr/local/lib --with-imap=/usr/local/imap-2007d --with-imap-ssl=/usr/local/ssl I would be happy to provide you additional debugging information. -Leif Neve -- Edit this bug report at http://bugs.php.net/?id=47230edit=1
#47409 [NEW]: extract() problem
From: niximor at gmail dot com
Operating system: Windows Vista
PHP version: 5.2.9RC2
PHP Bug Type: Scripting Engine problem
Bug description: extract() problem
Description:
When I use extract() with array, that contains key this, it behaves
really weird. See code for more info.
Reproduce code:
---
class Test1 {
var $name = test1;
}
class Test2 {
var $name = test2;
function bug() {
extract(array(this=new Test1()), EXTR_OVERWRITE | EXTR_REFS);
echo get_class($this).::name = .$this-name;
}
}
$t = new Test2();
$t-bug();
Expected result:
Test1::name = test1 (preferably)
OR
Test2::name = test2
- not combination of both.
Actual result:
--
Test1::name = test2
--
Edit bug report at http://bugs.php.net/?id=47409edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47409r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47409r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47409r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47409r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47409r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47409r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47409r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47409r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47409r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47409r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47409r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47409r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47409r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47409r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47409r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47409r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47409r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47409r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47409r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47409r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47409r=mysqlcfg
#47388 [Opn]: Array Foreach Reference Broken
ID: 47388
User updated by: martin at itmission dot com
Reported By: martin at itmission dot com
Status: Open
-Bug Type: Feature/Change Request
+Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.3.0beta1
New Comment:
Changed category
Previous Comments:
[2009-02-14 19:47:28] martin at itmission dot com
Description:
When using foreach on an array using the reference syntax, stuff breaks
later.
Reproduce code:
---
?php
$a = array(0, 1, 2, 3, 4);
foreach($a as $k = $v)
{
$v++;
}
foreach($a as $k = $v)
{
echo($k = $v\n);
}
?
Expected result:
0 = 1
1 = 2
2 = 3
3 = 4
4 = 5
Actual result:
--
0 = 1
1 = 2
2 = 3
3 = 4
4 = 4
--
Edit this bug report at http://bugs.php.net/?id=47388edit=1
#47388 [Com]: Array Foreach Reference Broken
ID: 47388
Comment by: martin at itmission dot com
Reported By: martin at itmission dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.3.0beta1
New Comment:
Also happens in 5.2.8
Previous Comments:
[2009-02-16 18:56:12] martin at itmission dot com
Changed category
[2009-02-14 19:47:28] martin at itmission dot com
Description:
When using foreach on an array using the reference syntax, stuff breaks
later.
Reproduce code:
---
?php
$a = array(0, 1, 2, 3, 4);
foreach($a as $k = $v)
{
$v++;
}
foreach($a as $k = $v)
{
echo($k = $v\n);
}
?
Expected result:
0 = 1
1 = 2
2 = 3
3 = 4
4 = 5
Actual result:
--
0 = 1
1 = 2
2 = 3
3 = 4
4 = 4
--
Edit this bug report at http://bugs.php.net/?id=47388edit=1
#47388 [Opn-Bgs]: Array Foreach Reference Broken
ID: 47388
Updated by: der...@php.net
Reported By: martin at itmission dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.3.0beta1
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:
[2009-02-16 18:57:13] martin at itmission dot com
Also happens in 5.2.8
[2009-02-16 18:56:12] martin at itmission dot com
Changed category
[2009-02-14 19:47:28] martin at itmission dot com
Description:
When using foreach on an array using the reference syntax, stuff breaks
later.
Reproduce code:
---
?php
$a = array(0, 1, 2, 3, 4);
foreach($a as $k = $v)
{
$v++;
}
foreach($a as $k = $v)
{
echo($k = $v\n);
}
?
Expected result:
0 = 1
1 = 2
2 = 3
3 = 4
4 = 5
Actual result:
--
0 = 1
1 = 2
2 = 3
3 = 4
4 = 4
--
Edit this bug report at http://bugs.php.net/?id=47388edit=1
#47388 [Bgs]: Array Foreach Reference Broken
ID: 47388
User updated by: martin at itmission dot com
Reported By: martin at itmission dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.3.0beta1
New Comment:
The error is in my code. Sorry. Always unset variables after a
foreach with a reference unless you know what you are doing.
unset($v);
Previous Comments:
[2009-02-16 19:15:58] der...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
.
[2009-02-16 18:57:13] martin at itmission dot com
Also happens in 5.2.8
[2009-02-16 18:56:12] martin at itmission dot com
Changed category
[2009-02-14 19:47:28] martin at itmission dot com
Description:
When using foreach on an array using the reference syntax, stuff breaks
later.
Reproduce code:
---
?php
$a = array(0, 1, 2, 3, 4);
foreach($a as $k = $v)
{
$v++;
}
foreach($a as $k = $v)
{
echo($k = $v\n);
}
?
Expected result:
0 = 1
1 = 2
2 = 3
3 = 4
4 = 5
Actual result:
--
0 = 1
1 = 2
2 = 3
3 = 4
4 = 4
--
Edit this bug report at http://bugs.php.net/?id=47388edit=1
#47410 [NEW]: array_combine crashing code when in the background
From: helenadeus at gmail dot com
Operating system: Linux
PHP version: 5.2CVS-2009-02-16 (snap)
PHP Bug Type: Arrays related
Bug description: array_combine crashing code when in the background
Description:
I'm running a script which tries to run something else in the
background, like such:
This code is inside a script called waiting.php
?php
popen(php -f stall.php tmp ','r');
?
and stall.php is:
?php
$V=array_combine(array('a','b','c'),array(1,2,3));
foreach ($V as $k=$v) {
echo $V[$k].chr(10);
}
?
It works fine... until I use the function array_combine in the
script stall.php
For some reason, even though this function works fine both in the
console and through apache, it crashes my code whenever I try to run
it in the background. Any thoughts on why this happens?
Reproduce code:
---
This code is inside a script called waiting.php
?php
popen(php -f stall.php tmp ','r');
?
and stall.php is:
?php
$V=array_combine(array('a','b','c'),array(1,2,3));
foreach ($V as $k=$v) {
echo $V[$k].chr(10);
}
?
Expected result:
tmp:
1
2
3
Actual result:
--
tmp is empty
--
Edit bug report at http://bugs.php.net/?id=47410edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47410r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47410r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47410r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47410r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47410r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47410r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47410r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47410r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47410r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47410r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47410r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47410r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47410r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47410r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47410r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47410r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47410r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47410r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47410r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47410r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47410r=mysqlcfg
#47370 [Opn-Asn]: array_unique has backward compatibility problem, and SORT_REGULAR is confusing
ID: 47370
Updated by: j...@php.net
Reported By: for-bugs at hnw dot jp
-Status: Open
+Status: Assigned
Bug Type: Arrays related
Operating System: any
PHP Version: 5.2.9RC1
-Assigned To:
+Assigned To: andrei
Previous Comments:
[2009-02-14 08:28:18] for-bugs at hnw dot jp
OK, you think comparing elements as string is harmful, doesn't you?
Then, how about array_diff() or array_intersect()? They compare array
elements with string representation. Isn't it harmful?
[2009-02-14 08:22:26] moriyo...@php.net
This was not discussed, and thus no bogus thing.
[2009-02-13 22:27:35] and...@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
The slight BC breakage is negligible compared to the benefits of
getting it to work properly.
[2009-02-13 01:53:09] for-bugs at hnw dot jp
Thank you so much. The snapshot returns same result to PHP 5.2.8 with
reproduce code. Such as:
array(2) {
[0]=
int(0)
[1]=
string(0)
}
array(2) {
[0]=
string(0)
[1]=
string(1) 0
}
[2009-02-12 18:58:34] moriyo...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
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/47370
--
Edit this bug report at http://bugs.php.net/?id=47370edit=1
#47412 [NEW]: PHP_MSHUTDOWN_FUNCTION not being called under FastCGI
From: tser at deltacontrols dot com
Operating system: Vista 64
PHP version: 5.2.9RC2
PHP Bug Type: CGI related
Bug description: PHP_MSHUTDOWN_FUNCTION not being called under FastCGI
Description:
Using FastCGI with IIS, the PHP_MSHUTDOWN_FUNCTION of any extensions are
not being called when the php_cgi.exe process is recycled.
PHP_MINIT_FUNCTION(xxx)
{
REGISTER_INI_ENTRIES();
}
PHP_MSHUTDOWN_FUNCTION(xxx)
{
UNREGISTER_INI_ENTRIES();
return SUCCESS;
}
It happens on our custom extension and any standard extension.
It could be easily duplicatable even by putting a break point on
PHP_MSHUTDOWN_FUNCTION in php_date.c
Reproduce code:
---
?phpinfo();?
Expected result:
PHP_MSHUTDOWN_FUNCTION being called.
Actual result:
--
PHP_MSHUTDOWN_FUNCTION not being called.
--
Edit bug report at http://bugs.php.net/?id=47412edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47412r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47412r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47412r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47412r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47412r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47412r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47412r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47412r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47412r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47412r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47412r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47412r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47412r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47412r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47412r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47412r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47412r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47412r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47412r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47412r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47412r=mysqlcfg
#47414 [NEW]: PDO_Firebird memory leaks when using bindColumn()
From: fel...@php.net
Operating system:
PHP version: 5.3CVS-2009-02-16 (CVS)
PHP Bug Type: PDO related
Bug description: PDO_Firebird memory leaks when using bindColumn()
Description:
See below.
Reproduce code:
---
?php
$db = new PDO('firebird:dbname=...', 'sysdba', 'foo');
$db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
@$db-exec('drop table test');
$db-exec('CREATE TABLE test(idx int NOT NULL PRIMARY KEY, txt
VARCHAR(20))');
$db-exec('INSERT INTO test VALUES(0, \'String0\')');
$stmt = $db-prepare('SELECT idx, txt FROM test ORDER by idx');
$idx = $txt = 0;
$stmt-bindColumn('IDX', $idx);
$stmt-bindColumn('TXT', $txt);
$stmt-execute();
while($stmt-fetch(PDO::FETCH_BOUND)) {
var_dump(array($idx=$txt));
}
Actual result:
--
array(1) {
[0]=
string(7) String0
}
[Mon Feb 16 19:30:09 2009] Script: '../test.php'
/home/felipe/dev/php5/main/spprintf.c(775) : Freeing 0x090E8A64 (79
bytes), script=../test.php
Last leak repeated 1 time
=== Total 2 memory leaks detected ===
--
Edit bug report at http://bugs.php.net/?id=47414edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47414r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47414r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47414r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47414r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47414r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47414r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47414r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47414r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47414r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47414r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47414r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47414r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47414r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47414r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47414r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47414r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47414r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47414r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47414r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47414r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47414r=mysqlcfg
#47415 [NEW]: PDO_Firebird segfaults when passing lowercased column name to bindColumn()
From: fel...@php.net
Operating system:
PHP version: 5.3CVS-2009-02-16 (CVS)
PHP Bug Type: PDO related
Bug description: PDO_Firebird segfaults when passing lowercased column name to
bindColumn()
Description:
The problem just happens when using lowercased column name in boundColumn
calls. Using uppercased occurs memleaks though. (probably related to
#47414)
Reproduce code:
---
?php
$db = new PDO('firebird:dbname=...', 'sysdba', 'foo');
$db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
@$db-exec('drop table test');
$db-exec('CREATE TABLE test(idx int NOT NULL PRIMARY KEY, txt
VARCHAR(20))');
$db-exec('INSERT INTO test VALUES(0, \'String0\')');
$stmt = $db-prepare('SELECT idx, txt FROM test ORDER by idx');
$idx = $txt = 0;
$stmt-bindColumn('idx', $idx);
$stmt-bindColumn('txt', $txt);
$stmt-execute();
$stmt-fetch(PDO::FETCH_BOUND);
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb79ee8e0 (LWP 5961)]
0x081d3466 in firebird_stmt_get_col (stmt=0x8c3ac5c, colno=-1,
ptr=0xbf7fb76c, len=0xbf7fb768, caller_frees=0xbf7fb764,
tsrm_ls=0x8af8050)
at /home/felipe/dev/php5/ext/pdo_firebird/firebird_statement.c:273
273 if (*var-sqlind == -1) {
(gdb) bt
#0 0x081d3466 in firebird_stmt_get_col (stmt=0x8c3ac5c, colno=-1,
ptr=0xbf7fb76c, len=0xbf7fb768, caller_frees=0xbf7fb764,
tsrm_ls=0x8af8050)
at /home/felipe/dev/php5/ext/pdo_firebird/firebird_statement.c:273
#1 0x081d47d9 in firebird_stmt_param_hook (stmt=0x8c3ac5c,
param=0x8c3b3d4, event_type=PDO_PARAM_EVT_FETCH_POST, tsrm_ls=0x8af8050)
at /home/felipe/dev/php5/ext/pdo_firebird/firebird_statement.c:555
#2 0x081c766e in dispatch_param_event (stmt=0x8c3ac5c,
event_type=PDO_PARAM_EVT_FETCH_POST, tsrm_ls=0x8af8050) at
/home/felipe/dev/php5/ext/pdo/pdo_stmt.c:184
#3 0x081c88d2 in do_fetch_common (stmt=0x8c3ac5c, ori=PDO_FETCH_ORI_NEXT,
offset=0, do_bind=1, tsrm_ls=0x8af8050) at
/home/felipe/dev/php5/ext/pdo/pdo_stmt.c:705
#4 0x081ca077 in do_fetch (stmt=0x8c3ac5c, do_bind=1,
return_value=0x8c3b238, how=PDO_FETCH_BOUND, ori=PDO_FETCH_ORI_NEXT,
offset=0, return_all=0x0,
tsrm_ls=0x8af8050) at /home/felipe/dev/php5/ext/pdo/pdo_stmt.c:934
#5 0x081cba40 in zim_PDOStatement_fetch (ht=1, return_value=0x8c3b238,
return_value_ptr=0x0, this_ptr=0x8c38100, return_value_used=0,
tsrm_ls=0x8af8050)
at /home/felipe/dev/php5/ext/pdo/pdo_stmt.c:1391
#6 0x084331b8 in zend_do_fcall_common_helper_SPEC
(execute_data=0x8c6745c, tsrm_ls=0x8af8050) at
/home/felipe/dev/php5/Zend/zend_vm_execute.h:313
#7 0x08434337 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x8c6745c, tsrm_ls=0x8af8050) at
/home/felipe/dev/php5/Zend/zend_vm_execute.h:422
--
Edit bug report at http://bugs.php.net/?id=47415edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47415r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47415r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47415r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47415r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47415r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47415r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47415r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47415r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47415r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47415r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47415r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47415r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47415r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47415r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47415r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47415r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47415r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47415r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47415r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47415r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47415r=mysqlcfg
#47416 [NEW]: Please add endclass, endfunction keywords.
From: mail at dropdev dot org
Operating system: Any
PHP version: 6CVS-2009-02-17 (CVS)
PHP Bug Type: Feature/Change Request
Bug description: Please add endclass, endfunction keywords.
Description:
Note: I'm aware of the won't fix on #24100
I'm re-requesting this feature, because this syntax actually helps people
working with php to debug their program.
Consider this:
When using curly braces, PHP gives an syntax error at the end of the file,
on a non-existing line (which confuses developpers), using an item ($end)
which looks like a php variable (which confuses developpers even more).
Also, the error message confuses lot's of developpers as can be seen in
the loads of issues popping on when searching for the error.
Now consider this:
When using endxxx statements, it gives a more meaningful, error message,
which is also a lot closer to the actual error position (a bless if you
have 1000+ lines of code in your difficult class)
Also, it is much easier to search for in the documentation (see:
http://php.net/manual/tokens.php which is on the first page of the search,
if you search sitewide for T_ENDFOREACH)
As a free bonus, using this alternative syntax also resolves the ongoing
discussion on where to place the curly braces (new line/no new line).
please also read: http://www.geocities.com/tablizer/endx.htm
The reproduce code contains two similar independent examamples showing the
primary and alternative syntax, each with 1 syntax error to show the
difference between the both.
Reproduce code:
---
?php
// example 1
$foobar = array('foo', 'bar');
if (TRUE):
if (TRUE):
foreach($foobar as $key = $value):
if (TRUE):
// some code
// also code
endforeach; // syntax error here!!! (unexpected T_ENDFOREACH)
endif;
else:
// more code
endif;
// example 2
$foobar = array('foo', 'bar');
if (TRUE) {
if (TRUE) {
foreach($foobar as $key = $value) {
if (TRUE) {
// some code...
// also code...
}
}
} else {
// more code ...
}
// syntax error here!!! (unexpected $end)
--
Edit bug report at http://bugs.php.net/?id=47416edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47416r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47416r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47416r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47416r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47416r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47416r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47416r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47416r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47416r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47416r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47416r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47416r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47416r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47416r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47416r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47416r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47416r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47416r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47416r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47416r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47416r=mysqlcfg
#47417 [NEW]: There is no footer function
From: henke at henke37 dot cjb dot net
Operating system:
PHP version: 6CVS-2009-02-17 (CVS)
PHP Bug Type: Feature/Change Request
Bug description: There is no footer function
Description:
There is no footer function to go with the header function. The http 1.1
rfc introduced reply footers, there should be a way to set those.
Reproduce code:
---
?php
$contents=ob_get_flush();
echo $contents
footer('MD5:'.md5($contents));
Expected result:
The footer should be sent.
Actual result:
--
The function does not exist.
--
Edit bug report at http://bugs.php.net/?id=47417edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47417r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47417r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47417r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47417r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47417r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47417r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47417r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47417r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47417r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47417r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47417r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47417r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47417r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47417r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47417r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47417r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47417r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47417r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47417r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47417r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47417r=mysqlcfg
