#48273 [Opn]: *_real_walk returns SNMP errors as values
ID: 48273
User updated by: lytboris at gmail dot com
Reported By: lytboris at gmail dot com
Status: Open
Bug Type: SNMP related
Operating System: FreeBSD
PHP Version: 5.2.9
New Comment:
Oups,
last line in Actual result should be read as
[NET-SNMP-MIB::netSnmp.2.1.2.3.8] => No more variables left in this
MIB
View (It is past the end of the MIB tree)
(wrong copy-paste)
Previous Comments:
[2009-05-14 06:46:49] lytboris at gmail dot com
Description:
When remote SNMP agent returns an error with same OID that contained
correct value *_real_walk functions will overwrite this correct value
with error message because there is no snmp reply status check.
Here is patch to address this issue:
--- ext/snmp/snmp.c.orig2008-12-31 14:17:43.0 +0300
+++ ext/snmp/snmp.c 2009-05-14 10:31:23.0 +0400
@@ -480,12 +480,15 @@
} else if (st == SNMP_CMD_WALK)
{
add_next_index_zval(return_value,snmpval); /* Add to returned array */
} else if (st ==
SNMP_CMD_REALWALK) {
+ if (vars->type !=
SNMP_ENDOFMIBVIEW &&
+ vars->type !=
SNMP_NOSUCHOBJECT && vars->type != SNMP_NOSUCHINSTANCE) {
#ifdef HAVE_NET_SNMP
- snprint_objid(buf2,
sizeof(buf2), vars->name, vars->name_length);
+
snprint_objid(buf2, sizeof(buf2), vars->name, vars->name_length);
#else
- sprint_objid(buf2,
vars->name, vars->name_length);
+
sprint_objid(buf2, vars->name, vars->name_length);
#endif
-
add_assoc_zval(return_value,buf2,snmpval);
+
add_assoc_zval(return_value,buf2,snmpval);
+ }
}
if (st >= SNMP_CMD_WALK && st
!= SNMP_CMD_SET) {
if (vars->type !=
SNMP_ENDOFMIBVIEW &&
in BASE64 form:
begin-base64 644 -
LS0tIGV4dC9zbm1wL3NubXAuYy5vcmlnCTIwMDgtMTItMzEgMTQ6MTc6NDMuMDAwMDAwMDAwICsw
MzAwCisrKyBleHQvc25tcC9zbm1wLmMJMjAwOS0wNS0xNCAxMDozMToyMy4wMDAwMDAwMDAgKzA0
MDAKQEAgLTQ4MCwxMiArNDgwLDE1IEBACiAJCQkJCX0gZWxzZSBpZiAoc3QgPT0gU05NUF9DTURf
V0FMSykgewogCQkJCQkJYWRkX25leHRfaW5kZXhfenZhbChyZXR1cm5fdmFsdWUsc25tcHZhbCk7
IC8qIEFkZCB0byByZXR1cm5lZCBhcnJheSAqLwogCQkJCQl9IGVsc2UgaWYgKHN0ID09IFNOTVBf
Q01EX1JFQUxXQUxLKSAgeworCQkJCQkJaWYgKHZhcnMtPnR5cGUgIT0gU05NUF9FTkRPRk1JQlZJ
RVcgJiYgCisJCQkJCQkJdmFycy0+dHlwZSAhPSBTTk1QX05PU1VDSE9CSkVDVCAmJiB2YXJzLT50
eXBlICE9IFNOTVBfTk9TVUNISU5TVEFOQ0UpIHsKICNpZmRlZiBIQVZFX05FVF9TTk1QCi0JCQkJ
CQlzbnByaW50X29iamlkKGJ1ZjIsIHNpemVvZihidWYyKSwgdmFycy0+bmFtZSwgdmFycy0+bmFt
ZV9sZW5ndGgpOworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgCXNucHJpbnRfb2JqaWQoYnVmMiwgc2l6ZW9mKGJ1ZjIpLCB2YXJzLT5uYW1lLCB2YXJzLT5u
YW1lX2xlbmd0aCk7CiAjZWxzZQotCQkJCQkJc3ByaW50X29iamlkKGJ1ZjIsIHZhcnMtPm5hbWUs
IHZhcnMtPm5hbWVfbGVuZ3RoKTsKKwkJCQkJCQlzcHJpbnRfb2JqaWQoYnVmMiwgdmFycy0+bmFt
ZSwgdmFycy0+bmFtZV9sZW5ndGgpOwogI2VuZGlmCi0JCQkJCQlhZGRfYXNzb2NfenZhbChyZXR1
cm5fdmFsdWUsYnVmMixzbm1wdmFsKTsKKwkJCQkJCQlhZGRfYXNzb2NfenZhbChyZXR1cm5fdmFs
dWUsYnVmMixzbm1wdmFsKTsKKwkJCQkJCX0KIAkJCQkJfQogCQkJCQlpZiAoc3QgPj0gU05NUF9D
TURfV0FMSyAmJiBzdCAhPSBTTk1QX0NNRF9TRVQpIHsKIAkJCQkJCWlmICh2YXJzLT50eXBlICE9
IFNOTVBfRU5ET0ZNSUJWSUVXICYmIAo=
Reproduce code:
---
print_r(@snmp2_real_walk("host:161", "community",
".1.3.6.1.4.1.8072.2.1.2.3", (800 * 1000), 2)):
===
Result shown by snmpwalk:
>snmpwalk -v2c -ccommunity host .1.3.6.1.4.1.8072.2.1.2.3
NET-SNMP-MIB::netSnmp.2.1.2.3.1 = ""
NET-SNMP-MIB::netSnmp.2.1.2.3.2 = ""
NET-SNMP-MIB::netSnmp.2.1.2.3.3 = ""
NET-SNMP-MIB::netSnmp.2.1.2.3.4 = ""
NET-SNMP-MIB::netSnmp.2.1.2.3.5 = ""
NET-SNMP-MIB::netSnmp.2.1.2.3.6 = ""
NET-SNMP-MIB::netSnmp.2.1.2.3.7 = ""
NET-SNMP-MIB::netSnmp.2.1.2.3.8 = STRING: "blah"
NET-SNMP-MIB::netSnmp.2.1.2.3.8 = No more variables left in this MIB
View (It is past the end of the MIB tree)
Expected result:
Array
(
[NET-SNMP-MIB::netSnmp.2.1.2.3.1] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.2] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.3] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.4] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.5] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.6] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.7] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.8] => "blah"
)
Actual result:
--
Array
(
[NET-SNMP-MIB::netSnmp.2.1.2.3.1] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.2] => ""
[NET
#48273 [NEW]: *_real_walk returns SNMP errors as values
From: lytboris at gmail dot com
Operating system: FreeBSD
PHP version: 5.2.9
PHP Bug Type: SNMP related
Bug description: *_real_walk returns SNMP errors as values
Description:
When remote SNMP agent returns an error with same OID that contained
correct value *_real_walk functions will overwrite this correct value with
error message because there is no snmp reply status check.
Here is patch to address this issue:
--- ext/snmp/snmp.c.orig2008-12-31 14:17:43.0 +0300
+++ ext/snmp/snmp.c 2009-05-14 10:31:23.0 +0400
@@ -480,12 +480,15 @@
} else if (st == SNMP_CMD_WALK) {
add_next_index_zval(return_value,snmpval); /* Add to returned array */
} else if (st ==
SNMP_CMD_REALWALK) {
+ if (vars->type !=
SNMP_ENDOFMIBVIEW &&
+ vars->type !=
SNMP_NOSUCHOBJECT && vars->type != SNMP_NOSUCHINSTANCE) {
#ifdef HAVE_NET_SNMP
- snprint_objid(buf2,
sizeof(buf2), vars->name, vars->name_length);
+
snprint_objid(buf2, sizeof(buf2), vars->name, vars->name_length);
#else
- sprint_objid(buf2,
vars->name, vars->name_length);
+ sprint_objid(buf2,
vars->name, vars->name_length);
#endif
-
add_assoc_zval(return_value,buf2,snmpval);
+
add_assoc_zval(return_value,buf2,snmpval);
+ }
}
if (st >= SNMP_CMD_WALK && st !=
SNMP_CMD_SET) {
if (vars->type !=
SNMP_ENDOFMIBVIEW &&
in BASE64 form:
begin-base64 644 -
LS0tIGV4dC9zbm1wL3NubXAuYy5vcmlnCTIwMDgtMTItMzEgMTQ6MTc6NDMuMDAwMDAwMDAwICsw
MzAwCisrKyBleHQvc25tcC9zbm1wLmMJMjAwOS0wNS0xNCAxMDozMToyMy4wMDAwMDAwMDAgKzA0
MDAKQEAgLTQ4MCwxMiArNDgwLDE1IEBACiAJCQkJCX0gZWxzZSBpZiAoc3QgPT0gU05NUF9DTURf
V0FMSykgewogCQkJCQkJYWRkX25leHRfaW5kZXhfenZhbChyZXR1cm5fdmFsdWUsc25tcHZhbCk7
IC8qIEFkZCB0byByZXR1cm5lZCBhcnJheSAqLwogCQkJCQl9IGVsc2UgaWYgKHN0ID09IFNOTVBf
Q01EX1JFQUxXQUxLKSAgeworCQkJCQkJaWYgKHZhcnMtPnR5cGUgIT0gU05NUF9FTkRPRk1JQlZJ
RVcgJiYgCisJCQkJCQkJdmFycy0+dHlwZSAhPSBTTk1QX05PU1VDSE9CSkVDVCAmJiB2YXJzLT50
eXBlICE9IFNOTVBfTk9TVUNISU5TVEFOQ0UpIHsKICNpZmRlZiBIQVZFX05FVF9TTk1QCi0JCQkJ
CQlzbnByaW50X29iamlkKGJ1ZjIsIHNpemVvZihidWYyKSwgdmFycy0+bmFtZSwgdmFycy0+bmFt
ZV9sZW5ndGgpOworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgCXNucHJpbnRfb2JqaWQoYnVmMiwgc2l6ZW9mKGJ1ZjIpLCB2YXJzLT5uYW1lLCB2YXJzLT5u
YW1lX2xlbmd0aCk7CiAjZWxzZQotCQkJCQkJc3ByaW50X29iamlkKGJ1ZjIsIHZhcnMtPm5hbWUs
IHZhcnMtPm5hbWVfbGVuZ3RoKTsKKwkJCQkJCQlzcHJpbnRfb2JqaWQoYnVmMiwgdmFycy0+bmFt
ZSwgdmFycy0+bmFtZV9sZW5ndGgpOwogI2VuZGlmCi0JCQkJCQlhZGRfYXNzb2NfenZhbChyZXR1
cm5fdmFsdWUsYnVmMixzbm1wdmFsKTsKKwkJCQkJCQlhZGRfYXNzb2NfenZhbChyZXR1cm5fdmFs
dWUsYnVmMixzbm1wdmFsKTsKKwkJCQkJCX0KIAkJCQkJfQogCQkJCQlpZiAoc3QgPj0gU05NUF9D
TURfV0FMSyAmJiBzdCAhPSBTTk1QX0NNRF9TRVQpIHsKIAkJCQkJCWlmICh2YXJzLT50eXBlICE9
IFNOTVBfRU5ET0ZNSUJWSUVXICYmIAo=
Reproduce code:
---
print_r(@snmp2_real_walk("host:161", "community",
".1.3.6.1.4.1.8072.2.1.2.3", (800 * 1000), 2)):
===
Result shown by snmpwalk:
>snmpwalk -v2c -ccommunity host .1.3.6.1.4.1.8072.2.1.2.3
NET-SNMP-MIB::netSnmp.2.1.2.3.1 = ""
NET-SNMP-MIB::netSnmp.2.1.2.3.2 = ""
NET-SNMP-MIB::netSnmp.2.1.2.3.3 = ""
NET-SNMP-MIB::netSnmp.2.1.2.3.4 = ""
NET-SNMP-MIB::netSnmp.2.1.2.3.5 = ""
NET-SNMP-MIB::netSnmp.2.1.2.3.6 = ""
NET-SNMP-MIB::netSnmp.2.1.2.3.7 = ""
NET-SNMP-MIB::netSnmp.2.1.2.3.8 = STRING: "blah"
NET-SNMP-MIB::netSnmp.2.1.2.3.8 = No more variables left in this MIB View
(It is past the end of the MIB tree)
Expected result:
Array
(
[NET-SNMP-MIB::netSnmp.2.1.2.3.1] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.2] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.3] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.4] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.5] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.6] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.7] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.8] => "blah"
)
Actual result:
--
Array
(
[NET-SNMP-MIB::netSnmp.2.1.2.3.1] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.2] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.3] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.4] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.5] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.6] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.7] => ""
[NET-SNMP-MIB::netSnmp.2.1.2.3.8] => No Such Instance currently exists
at this OID
)
--
Edit bug report at http://bugs.php.net/?id=48273&edit=1
--
Try a CVS snapshot (P
#48272 [Opn]: function valid , next, current ..from subclass of FilterIterator return false
ID: 48272
User updated by: gma625 at msn dot com
Reported By: gma625 at msn dot com
Status: Open
Bug Type: SPL related
Operating System: windows xp2
PHP Version: 5.2.9
New Comment:
hello, I'm the reporter of this bug, I'm sorry for making a typing
mistake below, I just get up to fix this typing mistake , But I don't
know how to achieve , so I post a new comment here, sorry for the
inconvience again .
mistake:
and the result is bool(true), it's very strange to get this while we
$cull->valid() it return false(true)
fix:
and the result is bool(true), it's very strange to get this while we
$cull->valid() it return bool(false)
Previous Comments:
[2009-05-14 03:39:08] gma625 at msn dot com
Description:
When extends a class with FilterIterator, the valid ,current,key, next
functions can't work, until you override your function with the
following codes
public function valid() {
$this->getInnerIterator()->valid();
}
btw, my php works version is 5.2.6, I can't found this version in the
select list , so I selected 5.2.9
Reproduce code:
---
error_reporting ( E_ALL | E_STRICT );
$array = array ('koala', 'kangaroo', 'wombat', 'wallaby', 'emu', 'NZ'
=> 'kiwi', 'kookaburra', 'platypus' );
class CullingIterator extends FilterIterator {
public function __construct(Iterator $it) {
parent::__construct ( $it );
}
function accept() {
$ittmp = $this->getInnerIterator ();
if ($ittmp->current () == 'koala') {
return false;
}
return true;
}
}
$cull = new CullingIterator ( new ArrayIterator ( $array ) );
try {
while ( $cull->valid () ) {
echo $cull->current ();
$cull->next ();
}
} catch ( Exception $e ) {
$e->getTraceAsString ();
}
Expected result:
print out the array result as following
kangaroowombatwallabyemukiwikookaburraplatypus
Actual result:
--
print nothing, becuase when we call $cull->valid() will return false
additional information , I've also tracked this problem by the
following code,
$cull = new CullingIterator ( new ArrayIterator ( $array ) );
$it = $cull->getInnerIterator();
var_dump( $it->valid() );
and the result is bool(true), it's very strange to get this while we
$cull->valid() it return false(true)
--
Edit this bug report at http://bugs.php.net/?id=48272&edit=1
#48272 [NEW]: function valid , next, current ..from subclass of FilterIterator return false
From: gma625 at msn dot com
Operating system: windows xp2
PHP version: 5.2.9
PHP Bug Type: SPL related
Bug description: function valid , next, current ..from subclass of
FilterIterator return false
Description:
When extends a class with FilterIterator, the valid ,current,key, next
functions can't work, until you override your function with the following
codes
public function valid() {
$this->getInnerIterator()->valid();
}
btw, my php works version is 5.2.6, I can't found this version in the
select list , so I selected 5.2.9
Reproduce code:
---
error_reporting ( E_ALL | E_STRICT );
$array = array ('koala', 'kangaroo', 'wombat', 'wallaby', 'emu', 'NZ' =>
'kiwi', 'kookaburra', 'platypus' );
class CullingIterator extends FilterIterator {
public function __construct(Iterator $it) {
parent::__construct ( $it );
}
function accept() {
$ittmp = $this->getInnerIterator ();
if ($ittmp->current () == 'koala') {
return false;
}
return true;
}
}
$cull = new CullingIterator ( new ArrayIterator ( $array ) );
try {
while ( $cull->valid () ) {
echo $cull->current ();
$cull->next ();
}
} catch ( Exception $e ) {
$e->getTraceAsString ();
}
Expected result:
print out the array result as following
kangaroowombatwallabyemukiwikookaburraplatypus
Actual result:
--
print nothing, becuase when we call $cull->valid() will return false
additional information , I've also tracked this problem by the following
code,
$cull = new CullingIterator ( new ArrayIterator ( $array ) );
$it = $cull->getInnerIterator();
var_dump( $it->valid() );
and the result is bool(true), it's very strange to get this while we
$cull->valid() it return false(true)
--
Edit bug report at http://bugs.php.net/?id=48272&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48272&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48272&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48272&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48272&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48272&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48272&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48272&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48272&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48272&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48272&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48272&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48272&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48272&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48272&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48272&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48272&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48272&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48272&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48272&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48272&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48272&r=mysqlcfg
#48271 [NEW]: fopen creates two files
From: my dot email dot subscriptions at gmail dot com
Operating system: windows xp spIII, Apache 2.2.3
PHP version: 5.2.9
PHP Bug Type: Filesystem function related
Bug description: fopen creates two files
Description:
Using this code I get two files written in my user directory.
$thisFilePointer = fopen( $tempFileName, 'x' );
die;
The first one is the file I named as "thisFile1.png", the second is the
same name plus 1, that is 'someFile2.png', both files are empty.
If I write an image, the first and second files contains two different
images, one is the image I want the other is alike but not the same
content.
If the file is a pdf file, I get two files also but the same content in
both of them.
Reproduce code:
---
$thisFile= $pdfFileName . $fileType;
$tempFileName= tempFilesDir . $thisFile;
$thisFilePointer = fopen( $tempFileName, 'x' );
if ( !$thisFilePointer ) {
# Here we prepare the error output into 'userErr';
trigger_error( userErr, E_USER_ERROR );
} //if
$fileHandler = fwrite( $thisFilePointer, $pdfContent );
if ( !$fileHandler ) {
# Here we prepare the error output into 'userErr';
trigger_error( userErr, E_USER_ERROR );
} //if
fclose( $thisFilePointer );
Expected result:
Get only one file with the desired content.
This did not happened to me under php 4
--
Edit bug report at http://bugs.php.net/?id=48271&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48271&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48271&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48271&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48271&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48271&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48271&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48271&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48271&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48271&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48271&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48271&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48271&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48271&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48271&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48271&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48271&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48271&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48271&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48271&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48271&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48271&r=mysqlcfg
#45877 [Csd]: Array key '2147483647' left as string
ID: 45877
Updated by: matt...@php.net
Reported By: henryptung at gmail dot com
Status: Closed
Bug Type: Arrays related
Operating System: CentOS 4
PHP Version: 5.2.6
Assigned To: mattwil
New Comment:
Also fixed in 5.2 now. See Bug #48254.
Previous Comments:
[2009-03-18 01:12:17] matt...@php.net
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.
Just fixed in 5.3 for now.
[2009-03-17 18:45:16] matt...@php.net
I had also noticed this issue awhile back. Finally created a simple fix
so it works consistently and as expected, and will apply it soon,
hopefully.
http://realplain.com/php/array_key_limit.diff
http://realplain.com/php/array_key_limit_5_3.diff
[2008-08-21 07:18:04] johan...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
use a 64bit machine for big integers
[2008-08-21 03:04:14] henryptung at gmail dot com
Description:
I believe '2147483647' (= 2^31 - 1) should be the standard
representation of a valid integer, but using the string form as an array
key stores the key as a string, not an integer. The integer key
2147483647 can be used separately to refer to a different value, and
both are stored. See repro code below:
Note: this bug is admittedly duplicate of bug #13407, but the bug still
exists, and I fail to understand why the original bug was marked bogus.
Thanks for your time.
Reproduce code:
---
$v = array('2147483647' => 'b', '2147483646' => 'c', 2147483647 =>
'd');
var_dump($v);
Expected result:
array(2) {
[2147483647]=>
string(1) "d"
[2147483646]=>
string(1) "c"
}
Actual result:
--
array(3) {
["2147483647"]=>
string(1) "b"
[2147483646]=>
string(1) "c"
[2147483647]=>
string(1) "d"
}
--
Edit this bug report at http://bugs.php.net/?id=45877&edit=1
#48254 [Asn->Csd]: Inconsistent handling of huge numerical keys for array
ID: 48254
Updated by: matt...@php.net
Reported By: for-bugs at hnw dot jp
-Status: Assigned
+Status: Closed
Bug Type: Arrays related
Operating System: *
-PHP Version: 5.2, 6CVS (2009-05-13)
+PHP Version: 5.2.9
Assigned To: mattwil
New Comment:
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.
Taken care of now!
I know, Jani, and I've merged other fixes. :-) Just thought this might
be considered, by others, more of a "feature change," since previous bug
reports had been dismissed. And Dmitry, nor anyone else, said anything
about including 5.2 when the change was made in HEAD/5.3 2 months
ago...
Nope, this has nothing to do with the other part missing from HEAD. ;-)
Even though I didn't personally commit this fix, it was done in HEAD as
well. (I've changed the reported version back to 5.2.9)
Previous Comments:
[2009-05-13 18:40:51] j...@php.net
Matt, bug fixes should go into PHP_5_2. And I guess this is the same
patch needing MFB to HEAD too? :)
[2009-05-13 14:25:42] matt...@php.net
See Bug #45877.
This has been fixed in PHP 5.3. I didn't backport the change to 5.2
since it's been around forever and didn't know if the fix would be
wanted in 5.2 (primarily by who's in charge of it) at this point in its
lifecycle.
I'll leave this open for now to see if other devs have a comment...
[2009-05-13 03:47:05] for-bugs at hnw dot jp
Description:
There is inconsistency in dealing with huge numerical array key.
We know PHP normalizes array key with numerical string to integer if
possible. For instance, $a["1"] is equevalent to $a[1]. However, it is
not valid about PHP_INT_MAX and ~PHP_INT_MAX (2147483647 and -2147483648
in 32bit envirionment).
Reproduce code:
---
int(2)
}
Actual result:
--
array(2) {
[2147483647]=>
int(1)
["2147483647"]=>
int(2)
}
--
Edit this bug report at http://bugs.php.net/?id=48254&edit=1
#42414 [Opn->Csd]: some odbc_*() functions incompatible with Oracle ODBC driver
ID: 42414 Updated by: fel...@php.net Reported By: jhml at gmx dot net -Status: Open +Status: Closed Bug Type: ODBC related Operating System: Linux PHP Version: 5.2.3 -Assigned To: +Assigned To: felipe New Comment: 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. Thanks for the patch. Previous Comments: [2007-08-28 09:12:49] jhml at gmx dot net I have examined all functions which take the cat argument now, which are: - odbc_tables - odbc_columns - odbc_columnprivileges - odbc_foreignkeys - odbc_primarykeys - odbc_procedurecolumns - odbc_procedures - odbc_specialcolumns - odbc_statistics - odbc_tableprivileges Most of these functions need to have cat == NULL (as long as one doesn't want to specify a catalog) with the Oracle ODBC driver. Interestingly, the follow functions don't have this requirement: - odbc_tables - odbc_procedurecolumns - odbc_procedures So I have created a patch now which sets cat to NULL for the functions which require it. The patch is available at http://www.bettina-attack.de/jonny/php-5.2.3-oracle_compat.diff [2007-08-25 11:08:41] jhml at gmx dot net Argh. Same problem with odbc_primarykeys(). Will examine the other functions also and create a new patch... [2007-08-24 16:27:08] jhml at gmx dot net Tested with MyODBC as well, no problems! [2007-08-24 13:38:16] jhml at gmx dot net I've tested IBM DB2 (iSeries ODBC driver from IBM), MS SQL (FreeTDS), Sybase (FreeTDS) and Oracle (native ODBC driver from Oracle). Moreover, NULL is also already passed when odbc_columns() is called with only one parameter. The patch may appear ugly but it's the same style as the Access workaround. IMHO it would be cleaner to allow passing a PHP-null to actually become a C-NULL, i.e. not forcing the String cast for null values, but that would be much more intrusive! [2007-08-24 13:15:14] j...@php.net Are you sure it doesn't break the other possible drivers..? 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/42414 -- Edit this bug report at http://bugs.php.net/?id=42414&edit=1
#48270 [NEW]: dba_open DB4 DB_HASH does not work
From: VJTD3 at VJTD3 dot com
Operating system: linux redhat fedora 10
PHP version: 5.2.9
PHP Bug Type: DBM/DBA related
Bug description: dba_open DB4 DB_HASH does not work
Description:
dba_open when used with the "driver" db4 defaults to btree but hash is
needed. (system databases are in hash not btree.) DB_HASH is not defined
and isn't passed when defined to the creation environment.
db.h
typedef enum {
DB_BTREE=1,
DB_HASH=2,
DB_RECNO=3,
DB_QUEUE=4,
DB_UNKNOWN=5
} DBTYPE;
example showing DB_HASH not defined
Reproduce code:
---
Expected result:
return the proper value and create a database in that format then using
dba_open.
Actual result:
--
dba_open does not accept the constant and only uses btree then hash is
needed by system files.
--
Edit bug report at http://bugs.php.net/?id=48270&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48270&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48270&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48270&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48270&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48270&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48270&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48270&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48270&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48270&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48270&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48270&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48270&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48270&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48270&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48270&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48270&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48270&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48270&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48270&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48270&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48270&r=mysqlcfg
#47712 [Opn->Asn]: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result()
ID: 47712
Updated by: johan...@php.net
Reported By: ninzya at inbox dot lv
-Status: Open
+Status: Assigned
Bug Type: MySQL related
Operating System: Windows XP
PHP Version: 5.3.0RC2
-Assigned To:
+Assigned To: mysql
Previous Comments:
[2009-05-12 09:42:13] ninzya at inbox dot lv
This bug is still present in PHP 5.3.0RC2 and is critical to me.
[2009-04-19 12:04:11] ninzya at inbox dot lv
Changed bug summary.
My configuration:
Apache 2.2,
PHP 5.3.0RC1 as module,
Windows XP SP3,
MySQL community server 5.1.33
Bug being hit during high concurrency running apache benchmark: "ab -c
30 -n 1". See previous posts for details.
[2009-04-12 15:08:30] ninzya at inbox dot lv
Please excuse me for the delay. I have been figuring out what's the
cause of this bug and finally i have something to come up with.
The problem is in mysql_free_result function. Not in itself, but it's
behavior has changed. Consider the following example from the PHP manual
on mysql_free_result:
Example #1 A mysql_free_result() example
This code with PHP 5.3.0 with mysqlnd will now fail under high
concurrency, because mysql_free_result will affect $row variable and
allow another threads to use it's zval to store data. I suspect that
mysql_free_result marks the referenced by $row data as 'free' and
another threads pick that zval up and work with it. As soon as you
release result, another thread may corrupt $row variable. Test this
example under high concurrency and you will get different values for
$row['id'] and $row['email']. Run 1 req. test and some of them will
fail to produce correct output.
In my framework i use mysql_free_result before referencing last fetched
row of result set very often, that's why i hit this bug 'randomly'.
I have another example i just tested, this is part of my framework. The
idea is the same - mysql_free_result is being called before actually
using fetched data array.
$con =mysql_pconnect( 'localhost', 'root', '');
mysql_select_db( 'ewe10');
$q =mysql_query( $sql ='SELECT id, title, keywords, descr,
template_id, `title`, `keywords`, `descr`, `template_id`
FROM pages
WHERE node_id =11
AND alt_name =\'welcome\'
LIMIT 0, 1;', $con);
$row =mysql_fetch_assoc( $q);
mysql_free_result( $q);
if( $row['id'] ===null || $row['template_id'] !=8567 || $row['title']
!='My test page' || $row['keywords'] !='asdasd' || $row['descr']
!='asdasd') {
trigger_error( 'FAIL!', E_USER_WARNING);
trigger_error( 'SQL: ' .$sql, E_USER_WARNING);
ob_start();
var_dump( $row);
trigger_error( ob_get_clean(), E_USER_WARNING);
die('NOT OK');
}
die('OK');
SQL for the table:
CREATE TABLE `ewe10`.`pages` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'unique page
id',
`node_id` int(10) unsigned NOT NULL COMMENT 'node id in which this
page is',
`title` varchar(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL
COMMENT 'page title',
`keywords` varchar(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL
COMMENT 'page keywords',
`descr` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT
'page description',
`template_id` int(10) unsigned DEFAULT NULL COMMENT 'template this
page is using (if NULL, template was deleted from database and this page
is stored as a backup)',
`type` enum('MAIN','PAGE') CHARACTER SET latin1 NOT NULL DEFAULT
'PAGE' COMMENT 'page type',
`alt_name` varchar(45) CHARACTER SET latin1 NOT NULL COMMENT 'page
alternative name',
`date_add` datetime NOT NULL COMMENT 'when page was added',
PRIMARY KEY (`id`),
UNIQUE KEY `NODE_ID_ALT_NAME` (`node_id`,`alt_name`) USING BTREE,
KEY `FK_pages_templates` (`template_id`),
KEY `TYPE` (`type`),
KEY `FK_pages_map` (`node_id`),
KEY `DATE_ADD` (`date_add`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=FIXED;
the only row in this table is shown on the screenshot i referenced in
previous report.
To address the issue more quickly, i would like to give you a hint -
after calling mysql_free_result there is no possibility to fetch any
more rows, so there's nothing to worry about mysql_fetch_*(), but there
is possibility that the last fetched row may be referenced. This means -
even if mysql_free_result was called, last fetched row must remain
locked in mysqlnd internal zval cache until the variable is
implicitly/explicitly unset.
[2009-04-07 13:21:59] johan...@php.net
Can you give me some more details about your system and the
configuration, please.
I spent some time with load testing different configurations now using
mysqlnd, pconnects, and PHP's thread-safe mode and wasn't able to
re
#48251 [Opn->Fbk]: Mysql selects/deletes rows it shouldn't when using IS NULL
ID: 48251
Updated by: johan...@php.net
Reported By: dan at manifestwebdesign dot com
-Status: Open
+Status: Feedback
Bug Type: MySQL related
Operating System: linux
PHP Version: 5.2.9
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.
PHP simply passes the query through to MySQL so the problem is
somewhere there. PLease provide a complete example including all CREATE
TABLE statements and version information (mysql server, mysql clien
library, ...)
Previous Comments:
[2009-05-12 22:06:30] dan at manifestwebdesign dot com
Description:
Mysql ignores the IS NULL in the WHERE statement when the query is
executed from php.
In the example I give, the AddressID is auto_increment primary key. As
you can see from the output, the address ID gets a value of 65 for the
inserted row. I then DELETE WHERE AddressID IS NULL and the row is
removed. It will also return the row when I execute SELECT * FROM
Address WHERE AddressID IS NULL.
It happens in with mysql_query, PDO::exec() or PDO::query() and with or
without ` around the table name.
Reproduce code:
---
//PHP 5.2.9 on Hostmonster.com
mysql_connect(DB_HOST, DB_USER, DB_PASSWORD);
mysql_select_db(DB_NAME);
mysql_query("INSERT INTO `Address` (StreetAddress) VALUES ('blah')");
$result = mysql_query("SELECT * FROM `Address`");
while($row = mysql_fetch_assoc($result)){
print_r($row);
}
mysql_query("DELETE FROM `Address` WHERE `AddressID` IS NULL");
$result = mysql_query("SELECT * FROM `Address`");
while($row = mysql_fetch_assoc($result)){
print_r($row);
}
Expected result:
Array ( [AddressID] => 65 [NameOrCompany] => [StreetAddress] => blah
[City] => [State] => [Zip] => [Country] => [DateTimeCreated] =>
[DateTimeModified] => ) Array ( [AddressID] => 65 [NameOrCompany] =>
[StreetAddress] => blah [City] => [State] => [Zip] => [Country] =>
[DateTimeCreated] => [DateTimeModified] => )
Actual result:
--
Array ( [AddressID] => 65 [NameOrCompany] => [StreetAddress] => blah
[City] => [State] => [Zip] => [Country] => [DateTimeCreated] =>
[DateTimeModified] => )
--
Edit this bug report at http://bugs.php.net/?id=48251&edit=1
#48266 [Opn->Bgs]: shorthand for array keryword
ID: 48266
Updated by: johan...@php.net
Reported By: zyss at mail dot zp dot ua
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Irrelevant
PHP Version: 5.2.9
New Comment:
{} would create simpler lead to conflicts for the parser, but semantics
will be discussed when this feature will be discussed the next time.
Previous Comments:
[2009-05-13 19:57:57] zyss at mail dot zp dot ua
Description:
One of the most frequently used keywords in PHP is "array".
It would be great to adopt just another construct from C/C++, namely
array constructor using curly brackets { }.
These are cases when PHP code is oversaturated with "array" word.
In this way it would be much easier to write and read PHP code.
I am aware of case #3928 and
http://wiki.php.net/rfc/shortsyntaxforarrays, but I think that curly
brackets would be more suitable than square brackets.
Noone seems to complain of how C/C++ arrays are constructed.
--
Edit this bug report at http://bugs.php.net/?id=48266&edit=1
#48267 [Opn->Bgs]: new "in" keyword as an alias of array_search
ID: 48267
Updated by: johan...@php.net
Reported By: zyss at mail dot zp dot ua
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Irrelevant
PHP Version: 5.2.9
New Comment:
We try to avoid adding keywords as that creates trouble with updates.
This particular feature has little benefit over the current, more
verbose way.
Previous Comments:
[2009-05-13 20:04:55] zyss at mail dot zp dot ua
Description:
Please add new keyword "in" to improve readability of a PHP code that
is an inline alias to array_search function.
For example:
if (array_search($item, $array)) { ... }
would be:
if ($item in $array) { ... }
Another example:
if (array_search($item, array('first', 'second', 'third'))) { ... }
would be:
if ($item in array('first', 'second', 'third')) { ... }
or ideally:
if ($item in {'first', 'second', 'third'}) { ... }
--
Edit this bug report at http://bugs.php.net/?id=48267&edit=1
#48268 [Opn->Bgs]: Special case of a function with single array argument
ID: 48268
Updated by: johan...@php.net
Reported By: zyss at mail dot zp dot ua
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Irrelevant
PHP Version: 5.2.9
New Comment:
This has been discussed multiple times ad is not planned for future
releases. Please check archives of the "internals" list for in-depth
discussions and arguements.
Previous Comments:
[2009-05-13 20:20:25] zyss at mail dot zp dot ua
Description:
I propose to add a special syntax (simplification) for a function
declared with just one argument. The idea is to remove array with its
brackets ( ) in the function call to improve readability and get rid of
unneeded array keyword. This feature is expected by many people who use
such type of functions as a replacement of the PHP's missing feature to
specify function's arguments by name.
For example:
function setParams(array $params) { /*...*/ }
Current call:
setParams(array('name' => 'foo', 'width' => 300, 'height' => 150));
Proposed call:
setParams('name' => 'foo', 'width' => 300, 'height' => 150);
--
Edit this bug report at http://bugs.php.net/?id=48268&edit=1
#48260 [Fbk->Opn]: Size of PHP file affects behaviour of virtual() or #include virtual
ID: 48260 User updated by: p dot tipper at lancaster dot ac dot uk Reported By: p dot tipper at lancaster dot ac dot uk -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Debian GNU/Linux 5.0.1 PHP Version: 5.3CVS-2009-05-13 (snap) New Comment: I initially saw it in PHP 5.2.5 but as requested by your bug tracking system I've tested it on "5.3CVS-2009-05-13 (snap)" as well (and thats the version the URLs in the bug report link to). Previous Comments: [2009-05-13 18:29:29] j...@php.net With what PHP version does this work and with what not? [2009-05-13 11:43:26] p dot tipper at lancaster dot ac dot uk Warning, URLs have gotten wrapped in bug report: Working: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=200 Buggy: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350 etc. [2009-05-13 11:41:57] p dot tipper at lancaster dot ac dot uk Description: When doing an #include virtual of a php file this seems to change to an include() call (and thus hit basedir restrictions) when the base PHP file reaches a certain size. Also connected with this behaviour is sub-virtual requests also stop working. This seems baffling as this behaviour should occur purely in Apache. Use of virtual() seems to also trigger this bug. Reproduce code: --- This URL works normally: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=200 This URL demonstrates the bug: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350 To see how this is affected by setting open_basedir="/usr/local/lib/php:/tmp:." then check these URLs: Working: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=200&basedir=1 Broken: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350&basedir=1 The "?amount=N" adds more output lines to the main PHP file thus changing its size in an easy manner. All code available from http://red-velvet.lancs.ac.uk:8080/~tipper/include/include-test.tar.gz Expected result: The #include virtual (or virtual()) data should continue to behave as normal, and shouldn't fall foul of basedir restrictions. The following block should always appear at the top of the output: This is an included file /~tipper/include/subdir/test.php Request was /~tipper/include/base/index.php?amount=200 This is an included file /~tipper/include/subdir/test2.php Request was /~tipper/include/base/index.php?amount=200 End of included file /~tipper/include/subdir/test2.php End of included file /~tipper/include/subdir/test.php (Where 200 will be whatever number you set for amount= ) Actual result: -- Once the amount goes above about 340 lines this seems to be the output (from http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350 ) This is an included file /~tipper/include/base/index.php Request was /~tipper/include/base/index.php?amount=350 End of included file /~tipper/include/base/index.php If you try this with open_basedir set to "/usr/local/lib/php:/tmp:." you get the following error (from http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350&basedir=1 ) Warning: main() [function.main]: open_basedir restriction in effect. File(/home/tipper/public_html/include/subdir/test.php) is not within the allowed path(s): (/usr/local/lib/php:/tmp:.) in /home/tipper/public_html/include/base/index.php on line 30 Warning: main(/home/tipper/public_html/include/subdir/test.php) [function.main]: failed to open stream: Operation not permitted in /home/tipper/public_html/include/base/index.php on line 30 Warning: main() [function.include]: Failed opening '/home/tipper/public_html/include/subdir/test.php' for inclusion (include_path='.:/usr/local/lib/php') in /home/tipper/public_html/include/base/index.php on line 30 -- Edit this bug report at http://bugs.php.net/?id=48260&edit=1
#48269 [Opn->Bgs]: Unexpected return in substr function with negative start parameter
ID: 48269 Updated by: j...@php.net Reported By: relo dot san at gmail dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: CentOS 5 PHP Version: 5.2.9 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. See bug #47298 Previous Comments: [2009-05-13 20:47:23] relo dot san at gmail dot com Description: >From manual: "If length is given and is positive, the string returned will contain at most length characters beginning from start (depending on the length of string). If string is less than or equal to start characters long, FALSE will be returned." This bug detected in PHP versions >= 5.2.8 Results on different versions and OS: PHP Version 5.2.5, Windows and linux: boolean: false PHP Version 5.2.8, CentOS: string(1) "1" PHP 5.2.8 (cli) (built: Feb 5 2009 21:21:13), MacOS: string(1) "1" PHP Version 5.2.9, CentOS: string(1) "1" Maby is mistake in manual and substr do not accept negative start param if string length less than start? Reproduce code: --- var_dump( substr( '1', -2, 1 ) ); Expected result: boolean: false Actual result: -- string(1) "1" -- Edit this bug report at http://bugs.php.net/?id=48269&edit=1
#48269 [NEW]: Unexpected return in substr function with negative start parameter
From: relo dot san at gmail dot com Operating system: CentOS 5 PHP version: 5.2.9 PHP Bug Type: Scripting Engine problem Bug description: Unexpected return in substr function with negative start parameter Description: >From manual: "If length is given and is positive, the string returned will contain at most length characters beginning from start (depending on the length of string). If string is less than or equal to start characters long, FALSE will be returned." This bug detected in PHP versions >= 5.2.8 Results on different versions and OS: PHP Version 5.2.5, Windows and linux: boolean: false PHP Version 5.2.8, CentOS: string(1) "1" PHP 5.2.8 (cli) (built: Feb 5 2009 21:21:13), MacOS: string(1) "1" PHP Version 5.2.9, CentOS: string(1) "1" Maby is mistake in manual and substr do not accept negative start param if string length less than start? Reproduce code: --- var_dump( substr( '1', -2, 1 ) ); Expected result: boolean: false Actual result: -- string(1) "1" -- Edit bug report at http://bugs.php.net/?id=48269&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48269&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48269&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48269&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48269&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48269&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48269&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48269&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48269&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48269&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48269&r=support Expected behavior: http://bugs.php.net/fix.php?id=48269&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48269&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48269&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48269&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48269&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48269&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48269&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48269&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48269&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48269&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48269&r=mysqlcfg
#48257 [Asn->Tbd]: PharData throws exception with non-phar tar
ID: 48257
Updated by: cel...@php.net
Reported By: cel...@php.net
-Status: Assigned
+Status: To be documented
Bug Type: PHAR related
Operating System: n/a
PHP Version: 5.3CVS-2009-05-13 (CVS)
Assigned To: cellog
New Comment:
fixed in HEAD, 5.3, and pecl/phar
documentation needs to state that phar.require_hash does not affect
plain tar files, thus:
will not fail if sometar.tar does not have a signature.
will fail if sometar.phar.tar does not contain a signature.
Previous Comments:
[2009-05-13 06:24:06] cel...@php.net
Description:
pear download Net_URL
php -r 'new PharData("Net_URL-1.0.15.tgz");'
results in exception, tar does not have signature.
--
Edit this bug report at http://bugs.php.net/?id=48257&edit=1
#48268 [NEW]: Special case of a function with single array argument
From: zyss at mail dot zp dot ua
Operating system: Irrelevant
PHP version: 5.2.9
PHP Bug Type: Feature/Change Request
Bug description: Special case of a function with single array argument
Description:
I propose to add a special syntax (simplification) for a function declared
with just one argument. The idea is to remove array with its brackets ( )
in the function call to improve readability and get rid of unneeded array
keyword. This feature is expected by many people who use such type of
functions as a replacement of the PHP's missing feature to specify
function's arguments by name.
For example:
function setParams(array $params) { /*...*/ }
Current call:
setParams(array('name' => 'foo', 'width' => 300, 'height' => 150));
Proposed call:
setParams('name' => 'foo', 'width' => 300, 'height' => 150);
--
Edit bug report at http://bugs.php.net/?id=48268&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48268&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48268&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48268&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48268&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48268&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48268&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48268&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48268&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48268&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48268&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48268&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48268&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48268&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48268&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48268&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48268&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48268&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48268&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48268&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48268&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48268&r=mysqlcfg
#48267 [NEW]: new "in" keyword as an alias of array_search
From: zyss at mail dot zp dot ua
Operating system: Irrelevant
PHP version: 5.2.9
PHP Bug Type: Feature/Change Request
Bug description: new "in" keyword as an alias of array_search
Description:
Please add new keyword "in" to improve readability of a PHP code that is
an inline alias to array_search function.
For example:
if (array_search($item, $array)) { ... }
would be:
if ($item in $array) { ... }
Another example:
if (array_search($item, array('first', 'second', 'third'))) { ... }
would be:
if ($item in array('first', 'second', 'third')) { ... }
or ideally:
if ($item in {'first', 'second', 'third'}) { ... }
--
Edit bug report at http://bugs.php.net/?id=48267&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48267&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48267&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48267&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48267&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48267&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48267&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48267&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48267&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48267&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48267&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48267&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48267&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48267&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48267&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48267&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48267&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48267&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48267&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48267&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48267&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48267&r=mysqlcfg
#48266 [NEW]: shorthand for array keryword
From: zyss at mail dot zp dot ua
Operating system: Irrelevant
PHP version: 5.2.9
PHP Bug Type: Feature/Change Request
Bug description: shorthand for array keryword
Description:
One of the most frequently used keywords in PHP is "array".
It would be great to adopt just another construct from C/C++, namely array
constructor using curly brackets { }.
These are cases when PHP code is oversaturated with "array" word.
In this way it would be much easier to write and read PHP code.
I am aware of case #3928 and http://wiki.php.net/rfc/shortsyntaxforarrays,
but I think that curly brackets would be more suitable than square
brackets.
Noone seems to complain of how C/C++ arrays are constructed.
--
Edit bug report at http://bugs.php.net/?id=48266&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48266&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48266&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48266&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48266&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48266&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48266&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48266&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48266&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48266&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48266&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48266&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48266&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48266&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48266&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48266&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48266&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48266&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48266&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48266&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48266&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48266&r=mysqlcfg
#48265 [NEW]: Source and result of database have different encodings.
From: rodsouza at celepar dot pr dot gov dot br
Operating system: Debian Lenny
PHP version: 6CVS-2009-05-13 (snap)
PHP Bug Type: *Unicode Issues
Bug description: Source and result of database have different encodings.
Description:
When I try to access an array by a key that was created by
'pg_fetch_array' or 'PDOStatement::fetchAll' the result is 'NULL'.
Reproduce code:
---
$sql = "SELECT * from phpgw_config WHERE config_app='phpgwapi' and
config_name='webserver_url'";
##
#Result
#
#Array
#(
# [config_app] => phpgwapi
# [config_name] => webserver_url
# [config_value] => /expresso
#)
##
( $conn = pg_pconnect("dbname=expresso user=postgres") )
or die( 'A error occured at line #' . __FILE__ . "\n" );
( $result = pg_query($conn, $sql ) )
or die( 'A error occured at line #' . __FILE__ . "\n" );
$config = array( );
$config[ 'something' ] = array(
'key_1' => 'anything',
'key_2' => 'otherthing'
);
$config[ 'server' ] = pg_fetch_array( $result, NULL, PGSQL_ASSOC );
var_dump( $config[ 'server' ][ 'config_name' ] );
try
{
$pdo = new PDO('pgsql:dbname=expresso', 'postgres');
$pdo_stmt = $pdo -> prepare( $sql );
$pdo_stmt -> execute( );
$config[ 'server' ] = $pdo_stmt -> fetch( PDO::FETCH_ASSOC );
var_dump( $config[ 'server' ][ 'config_name' ] );
}
catch ( PDOException $e )
{
echo 'PDO ERROR: ' . $e -> getMessage( );
}
Expected result:
webserver_url
webserver_url
Actual result:
--
NULL
NULL
-
If:
var_dump( $config[ 'server' ][ b'config_name' ] );
The result is 'webserver_url'.
The problem is that I have a great application that have 1146 PHP files
and it is impossible to search for all the places that need this change.
--
Edit bug report at http://bugs.php.net/?id=48265&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48265&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48265&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48265&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48265&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48265&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48265&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48265&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48265&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48265&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48265&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48265&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48265&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48265&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48265&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48265&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48265&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48265&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48265&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48265&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48265&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48265&r=mysqlcfg
#48254 [Opn->Asn]: Inconsistent handling of huge numerical keys for array
ID: 48254
Updated by: j...@php.net
Reported By: for-bugs at hnw dot jp
-Status: Open
+Status: Assigned
Bug Type: Arrays related
Operating System: *
-PHP Version: 5.2.9
+PHP Version: 5.2, 6CVS (2009-05-13)
-Assigned To:
+Assigned To: mattwil
New Comment:
Matt, bug fixes should go into PHP_5_2. And I guess this is the same
patch needing MFB to HEAD too? :)
Previous Comments:
[2009-05-13 14:25:42] matt...@php.net
See Bug #45877.
This has been fixed in PHP 5.3. I didn't backport the change to 5.2
since it's been around forever and didn't know if the fix would be
wanted in 5.2 (primarily by who's in charge of it) at this point in its
lifecycle.
I'll leave this open for now to see if other devs have a comment...
[2009-05-13 03:47:05] for-bugs at hnw dot jp
Description:
There is inconsistency in dealing with huge numerical array key.
We know PHP normalizes array key with numerical string to integer if
possible. For instance, $a["1"] is equevalent to $a[1]. However, it is
not valid about PHP_INT_MAX and ~PHP_INT_MAX (2147483647 and -2147483648
in 32bit envirionment).
Reproduce code:
---
int(2)
}
Actual result:
--
array(2) {
[2147483647]=>
int(1)
["2147483647"]=>
int(2)
}
--
Edit this bug report at http://bugs.php.net/?id=48254&edit=1
#48255 [Opn->Ver]: Mixing control structure syntaxes causes parse error
ID: 48255
Updated by: j...@php.net
Reported By: faisun at sina dot com
-Status: Open
+Status: Verified
Bug Type: Scripting Engine problem
Operating System: *
-PHP Version: 5.2.9
+PHP Version: 5.*, 6CVS (2009-05-12)
Previous Comments:
[2009-05-13 04:05:30] faisun at sina dot com
Description:
PHP Version: 5.2.9.2
1):
echo "ABCD";
if(4>3){ echo "EFGH"; }
else:
echo "123456";
endif;
?>
Result: Parse error: parse error in E:\wwwroot\1.php on line 5
1):
echo "ABCD";
if(4>3){ echo "EFGH"; } else{}
else:
echo "123456";
endif;
?>
Result:ABCDEFGH
Reproduce code:
---
1):
echo "ABCD";
if(4>3){ echo "EFGH"; }
else:
echo "123456";
endif;
?>
Expected result:
ABCDEFGH
Actual result:
--
Parse error: parse error in E:\wwwroot\1.php on line 5
--
Edit this bug report at http://bugs.php.net/?id=48255&edit=1
#48256 [Opn->Bgs]: Crash due to double-linking of history.o
ID: 48256 Updated by: j...@php.net Reported By: tstarling at wikimedia dot org -Status: Open +Status: Bogus Bug Type: Readline related Operating System: Linux PHP Version: 5.3.0RC2 New Comment: Linux distro problems are not PHP bugs. Previous Comments: [2009-05-13 06:11:47] tstarling at wikimedia dot org Description: The readline extension links both libreadline and libhistory. This is unnecessary, and inspection of the readline example programs since version 2.0 implies that it has always been unnecessary. Both libraries include history.o, so linking to both gives you two copies of that module. The bug occurs when, due to operating system vagaries, libhistory loads before libreadline. This causes PHP's readline_add_history() to add history entries to libhistory's copy of the_history. Then when readline() is called, libreadline attempts to read the other copy of the_history. The result is a null pointer dereference in libreadline's previous_history() function. The libraries are loaded in the problematic order in Ubuntu 9.04, previous versions of Ubuntu appeared to work. The solution is to remove all references to libhistory in ext/readline/config.m4. I have patched this in and tested it. http://tstarling.com/stuff/fix-php-readline.patch Reproduce code: --- ' ); ?> Note that you can reproduce the problematic link order using: LD_PRELOAD=/lib/libhistory.so.5 php bug-demo.php It demonstrates the bug, but it will not give a successful resolution after the patch is applied. Expected result: Press the up arrow, it shows "test". Actual result: -- After pressing the up arrow: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb741a6e0 (LWP 27236)] 0xb7e87c18 in previous_history () at /home/tstarling/src/readline/readline5-5.2/history.c:186 186 return history_offset ? the_history[--history_offset] : (HIST_ENTRY *)NULL; (gdb) bt #0 0xb7e87c18 in previous_history () at /home/tstarling/src/readline/readline5-5.2/history.c:186 #1 0xb7e8727d in rl_get_previous_history (count=1, key=65) at /home/tstarling/src/readline/readline5-5.2/misc.c:526 #2 0xb7e6e057 in _rl_dispatch_subseq (key=65, map=0x90ff478, got_subseq=0) at /home/tstarling/src/readline/readline5-5.2/readline.c:742 #3 0xb7e6e2d8 in _rl_dispatch_subseq (key=91, map=0xb7e909e0, got_subseq=0) at /home/tstarling/src/readline/readline5-5.2/readline.c:831 #4 0xb7e6e2d8 in _rl_dispatch_subseq (key=27, map=0xb7e901c0, got_subseq=0) at /home/tstarling/src/readline/readline5-5.2/readline.c:831 #5 0xb7e6e484 in _rl_dispatch (key=27, map=0xb7e901c0) at /home/tstarling/src/readline/readline5-5.2/readline.c:692 #6 0xb7e6e8bd in readline_internal_char () at /home/tstarling/src/readline/readline5-5.2/readline.c:519 #7 0xb7e6ed3d in readline (prompt=0x8bc02b0 "> ") at /home/tstarling/src/readline/readline5-5.2/readline.c:545 #8 0x082bcd6d in zif_readline (ht=1, return_value=0xb71b5488, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) ... -- Edit this bug report at http://bugs.php.net/?id=48256&edit=1
#48260 [Opn->Fbk]: Size of PHP file affects behaviour of virtual() or #include virtual
ID: 48260 Updated by: j...@php.net Reported By: p dot tipper at lancaster dot ac dot uk -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Debian GNU/Linux 5.0.1 PHP Version: 5.3CVS-2009-05-13 (snap) New Comment: With what PHP version does this work and with what not? Previous Comments: [2009-05-13 11:43:26] p dot tipper at lancaster dot ac dot uk Warning, URLs have gotten wrapped in bug report: Working: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=200 Buggy: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350 etc. [2009-05-13 11:41:57] p dot tipper at lancaster dot ac dot uk Description: When doing an #include virtual of a php file this seems to change to an include() call (and thus hit basedir restrictions) when the base PHP file reaches a certain size. Also connected with this behaviour is sub-virtual requests also stop working. This seems baffling as this behaviour should occur purely in Apache. Use of virtual() seems to also trigger this bug. Reproduce code: --- This URL works normally: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=200 This URL demonstrates the bug: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350 To see how this is affected by setting open_basedir="/usr/local/lib/php:/tmp:." then check these URLs: Working: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=200&basedir=1 Broken: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350&basedir=1 The "?amount=N" adds more output lines to the main PHP file thus changing its size in an easy manner. All code available from http://red-velvet.lancs.ac.uk:8080/~tipper/include/include-test.tar.gz Expected result: The #include virtual (or virtual()) data should continue to behave as normal, and shouldn't fall foul of basedir restrictions. The following block should always appear at the top of the output: This is an included file /~tipper/include/subdir/test.php Request was /~tipper/include/base/index.php?amount=200 This is an included file /~tipper/include/subdir/test2.php Request was /~tipper/include/base/index.php?amount=200 End of included file /~tipper/include/subdir/test2.php End of included file /~tipper/include/subdir/test.php (Where 200 will be whatever number you set for amount= ) Actual result: -- Once the amount goes above about 340 lines this seems to be the output (from http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350 ) This is an included file /~tipper/include/base/index.php Request was /~tipper/include/base/index.php?amount=350 End of included file /~tipper/include/base/index.php If you try this with open_basedir set to "/usr/local/lib/php:/tmp:." you get the following error (from http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350&basedir=1 ) Warning: main() [function.main]: open_basedir restriction in effect. File(/home/tipper/public_html/include/subdir/test.php) is not within the allowed path(s): (/usr/local/lib/php:/tmp:.) in /home/tipper/public_html/include/base/index.php on line 30 Warning: main(/home/tipper/public_html/include/subdir/test.php) [function.main]: failed to open stream: Operation not permitted in /home/tipper/public_html/include/base/index.php on line 30 Warning: main() [function.include]: Failed opening '/home/tipper/public_html/include/subdir/test.php' for inclusion (include_path='.:/usr/local/lib/php') in /home/tipper/public_html/include/base/index.php on line 30 -- Edit this bug report at http://bugs.php.net/?id=48260&edit=1
#48247 [Opn->Asn]: PHP crashes on errors during startup
ID: 48247 Updated by: j...@php.net Reported By: dmi...@php.net -Status: Open +Status: Assigned Bug Type: Date/time related Operating System: * PHP Version: 5.*, 6CVS (2009-05-12) -Assigned To: jani +Assigned To: derick New Comment: I fixed the first part (dependancy issues + loading order), Derick can now fix the second part and add infinite recursion protection and make init tzcache be done in GINIT _and_ RINIT (if ! init -> init.. :) Previous Comments: [2009-05-13 07:09:31] dmi...@php.net Unfortunately this patch doesn't fix the bug. [2009-05-13 00:46:26] j...@php.net Dmitry, I committed a fix in HEAD. Please check it out. If you agree, I'll MFH to other branches. [2009-05-12 17:11:00] j...@php.net And of course this problem exists in all branches. [2009-05-12 16:31:46] j...@php.net See also bug #37111 which is similar problem, just during shutdown. [2009-05-12 16:09:53] dmi...@php.net Description: PHP crashes in case of warning messages during MINIT(). In case of warning messages during MINIT() the php_log_err() function is called. In case error_log directive is set to log errors into file this function tries to add timestamp using formatting through php_format_date(). However it leads PHP into infinity recursion if TZ isn't set, because php_format_date() throws another warning. Even preventing the recursion with static flag makes PHP crash in ext/date because of uninitialized DATEG(tzcache). #0 0x084922d2 in zend_hash_find (ht=0x89e9ac8, arKey=0x857edbd "Europe/Moscow", nKeyLength=14, pData=0xceac) at /home/dmitry/php/php5.3/Zend/zend_hash.c:880 #1 0x08142ff1 in php_date_parse_tzfile ( formal_tzname=0x857edbd "Europe/Moscow", tzdb=0x85cb9c8) at /home/dmitry/php/php5.3/ext/date/php_date.c:813 #2 0x081432a9 in get_timezone_info () at /home/dmitry/php/php5.3/ext/date/php_date.c:917 #3 0x08144d8c in php_format_date (format=0x899b203 "d-M-Y H:i:s", format_len=11, ts=1242143549, localtime=1) at /home/dmitry/php/php5.3/ext/date/php_date.c:1166 #4 0x08415f16 in php_log_err ( log_message=0xf7f8f678 "PHP Warning: test in Unknown on line 0") at /home/dmitry/php/php5.3/main/main.c:547 #5 0x08416db9 in php_error_cb (type=2, error_filename=0x89b00cf "Unknown", error_lineno=0, format=0x899bb97 "test", args=0xd088 "\005") at /home/dmitry/php/php5.3/main/main.c:958 #6 0x084832d2 in zend_error (type=2, format=0x899bb97 "test") at /home/dmitry/php/php5.3/Zend/zend.c:1020 #7 0x08418ecf in php_module_startup (sf=0x89d11a0, additional_modules=0x0, num_additional_modules=0) at /home/dmitry/php/php5.3/main/main.c:2021 #8 0x08546f59 in php_cli_startup (sapi_module=0x89d11a0) at /home/dmitry/php/php5.3/sapi/cli/php_cli.c:399 -- Edit this bug report at http://bugs.php.net/?id=48247&edit=1
#48263 [Opn->Bgs]: imposible to set quality compression
ID: 48263 Updated by: paj...@php.net Reported By: polkila at gmail dot com -Status: Open +Status: Bogus Bug Type: *Graphics related Operating System: FreeBSD 7.0-RELEASE i386 GENERIC PHP Version: 5.2.9 New Comment: Please report bugs in pecl. Previous Comments: [2009-05-13 15:25:50] polkila at gmail dot com Description: setCompressionQuality() is not working Reproduce code: --- $img = new Imagick($s_file); $img->setCompression(Imagick::COMPRESSION_JPEG); $img->setCompressionQuality(20); Expected result: changing quality of destination image Actual result: -- not changing -- Edit this bug report at http://bugs.php.net/?id=48263&edit=1
#45002 [Com]: __get() and __set() don't work for static variable calls
ID: 45002
Comment by: rcavallari at hotmail dot com
Reported By: jb2386 at hotmail dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Any
PHP Version: 5.2.6
New Comment:
Any news about __{get,set}Static in the mainline?
Previous Comments:
[2009-01-08 08:51:30] jeremie dot bordier at gmail dot com
Could this patch be reviewed and committed ? It's been a long time now
for a such little feature...
[2008-11-25 03:50:55] cleeder at gmail dot com
How long until we can expect to see this patch in the production
version of PHP?
[2008-09-13 14:42:23] the...@php.net
There is a patch available at
http://sitten-polizei.de/php/getstatic.diff
[2008-05-15 08:42:05] jb2386 at hotmail dot com
Description:
As per bug report: http://bugs.php.net/bug.php?id=39678
"Static class attributes cannot be accessed using __get and
__set methods."
Also, for reference to "__callStatic" see:
http://bugs.php.net/bug.php?id=26739
With the implementation of __callStatic in PHP 5.3, will there be an
implementation of similar functions __getStatic() and __setStatic()?
For example, so replacing __get and __set with __getStatic() and
__setStatic() respectively will produce the "Expected Output" below?
Reproduce code:
---
class myClass {
public function __set($name,$value) {
echo "Setting: " . $name . " to " . $value."\n";
self::$$name = $value;
}
public function __get($name) {
echo "Getting: " . $name . "\n";
}
}
myClass::$myStaticVar = "test";
echo myClass::$myStaticVar;
Expected result:
Setting: myStaticVar to test
Getting: myStaticVar
Actual result:
--
Fatal error: Access to undeclared static property:
myClass::$myStaticVar
--
Edit this bug report at http://bugs.php.net/?id=45002&edit=1
#48263 [NEW]: imposible to set quality compression
From: polkila at gmail dot com Operating system: FreeBSD 7.0-RELEASE i386 GENERIC PHP version: 5.2.9 PHP Bug Type: *Graphics related Bug description: imposible to set quality compression Description: setCompressionQuality() is not working Reproduce code: --- $img = new Imagick($s_file); $img->setCompression(Imagick::COMPRESSION_JPEG); $img->setCompressionQuality(20); Expected result: changing quality of destination image Actual result: -- not changing -- Edit bug report at http://bugs.php.net/?id=48263&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48263&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48263&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48263&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48263&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48263&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48263&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48263&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48263&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48263&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48263&r=support Expected behavior: http://bugs.php.net/fix.php?id=48263&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48263&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48263&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48263&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48263&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48263&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48263&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48263&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48263&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48263&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48263&r=mysqlcfg
#44996 [Opn->Csd]: [PATCH] xmlrpc_decode() ignores time zone on iso8601.datetime
ID: 44996
Updated by: il...@php.net
Reported By: helixpip at gmail dot com
-Status: Open
+Status: Closed
Bug Type: XMLRPC-EPI related
Operating System: *
PHP Version: 5.*, 6CVS (2009-01-21)
New Comment:
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.
Previous Comments:
[2009-01-09 10:00:44] kawai at apache dot org
Following is a patch for timezone problem.
The patch will fix the bug even if xmlrpc-epi did not parse timezone
correctly. xmlrpc-epi should be patched as
http://sourceforge.net/tracker2/?
func=detail&aid=2495315&group_id=23199&atid=377730.
--- ext/xmlrpc/xmlrpc-epi-php.c.orig2008-07-19 02:34:07.0
+0900
+++ ext/xmlrpc/xmlrpc-epi-php.c 2009-01-10 03:39:19.0 +0900
@@ -1300,7 +1300,7 @@
if(newtype == xmlrpc_datetime) {
XMLRPC_VALUE v =
XMLRPC_CreateValueDateTime_ISO8601(NULL, value->value.str.val);
if(v) {
- time_t timestamp =
XMLRPC_GetValueDateTime(v);
+ time_t timestamp =
(time_t)php_parse_date(XMLRPC_GetValueDateTime_ISO8601(v), NULL);
if(timestamp) {
zval* ztimestamp;
[2008-12-05 17:01:43] helixpip at gmail dot com
Just tested with 5.2.7. The behavior has changed, but it's still not
working correctly. The 'scalar' property now returns the original text
of the string passed in the tags, which is good. The
conversion of this string to a timestamp that is stored in the
'timestamp' property still appears to be ignoring the timezone
designator, however. Previously, it ignored the timezone designator and
assumed local time. Now, it appears to ignore the timezone designator
and assume Zulu time. Strtotime() still gives the correct timestamp in
all cases. Results of tests:
ISO 8601 datetime 20010909T01:46:40Z
strtotime yields 10
xmlrpc_decode
yields stdClass Object
(
[scalar] => 20010909T01:46:40Z
[xmlrpc_type] => datetime
[timestamp] => 10
)
ISO 8601 datetime 20010909T00:46:40-01
strtotime yields 10
xmlrpc_decode
yields stdClass Object
(
[scalar] => 20010909T00:46:40-01
[xmlrpc_type] => datetime
[timestamp] => 96400
)
ISO 8601 datetime 2001-09-09T08:46:40+07:00
strtotime yields 10
xmlrpc_decode
yields stdClass Object
(
[scalar] => 2001-09-09T08:46:40+07:00
[xmlrpc_type] => datetime
[timestamp] => 125200
)
ISO 8601 datetime 2001-09-08T21:46:40-0400
strtotime yields 10
xmlrpc_decode
yields stdClass Object
(
[scalar] => 2001-09-08T21:46:40-0400
[xmlrpc_type] => datetime
[timestamp] => 85600
)
[2008-06-05 05:28:57] kawai at apache dot org
Now, you can download patched version of xmlrpc extension from:
http://mp.i-revo.jp/user.php/kcvcrlkq/entry/313.html
I hope this patch to be applied in the next PHP release.
[2008-05-14 18:14:24] helixpip at gmail dot com
I wrote:
>Ideally the scalar property should explicitly be
>a UTC ISO 8601 datetime value, ending with the
>time zone designator 'Z'.
On second thought, it might be more useful for a php script to know
what, if any, time zone designator appeared with the original iso8601
datetime value. (At the moment there's no way to find this information
without parsing the xml.) If the scalar property preserved the original
time zone designator, that would help with this.
[2008-05-14 17:47:07] helixpip at gmail dot com
Description:
The xmlrpc_decode function does not correctly interpret ISO 8601
timezone designations when interpreting XML-RPC datetime values passed
in tags. It appears that the time zone designator is
completely ignored and the local time zone is assumed. (The
xmlrpc_decode_request function shows the same behavior.)
A side effect of this bug is that the 'scalar' and 'timestamp' objects
returned for XML-RPC datetime values will disagree if the object is used
is used in a different time zone than it was created. Ideally the
scalar property should explicitly be a UTC ISO 8601 datetime value,
ending with the time zone designator 'Z'.
Reproduce code:
---
function DecodeDatetime($datetime) {
print "\nISO 8601 datetime $datetime\n";
print "strtotime yields " . strtotime(
#48254 [Opn]: Inconsistent handling of huge numerical keys for array
ID: 48254
Updated by: matt...@php.net
Reported By: for-bugs at hnw dot jp
Status: Open
Bug Type: Arrays related
Operating System: any
PHP Version: 5.2.9
New Comment:
See Bug #45877.
This has been fixed in PHP 5.3. I didn't backport the change to 5.2
since it's been around forever and didn't know if the fix would be
wanted in 5.2 (primarily by who's in charge of it) at this point in its
lifecycle.
I'll leave this open for now to see if other devs have a comment...
Previous Comments:
[2009-05-13 03:47:05] for-bugs at hnw dot jp
Description:
There is inconsistency in dealing with huge numerical array key.
We know PHP normalizes array key with numerical string to integer if
possible. For instance, $a["1"] is equevalent to $a[1]. However, it is
not valid about PHP_INT_MAX and ~PHP_INT_MAX (2147483647 and -2147483648
in 32bit envirionment).
Reproduce code:
---
int(2)
}
Actual result:
--
array(2) {
[2147483647]=>
int(1)
["2147483647"]=>
int(2)
}
--
Edit this bug report at http://bugs.php.net/?id=48254&edit=1
#48261 [Opn->Bgs]: Paamayim Nekudotayim on class variables
ID: 48261
Updated by: der...@php.net
Reported By: bla at bla dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows
PHP Version: 5.3.0RC2
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
.
Previous Comments:
[2009-05-13 13:15:59] bla at bla dot com
Description:
just look @ the code
Reproduce code:
---
b = new B;
}
}
class B {
const text = "Hello World";
}
$a = new A;
var_dump($a);
var_dump($a->b);
var_dump($a->b::text); // Error
var_dump(($a->b)::text);// Error
$b = $a->b;
var_dump($b::text); // Works
?>
--
Edit this bug report at http://bugs.php.net/?id=48261&edit=1
#48261 [NEW]: Paamayim Nekudotayim on class variables
From: bla at bla dot com
Operating system: Windows
PHP version: 5.3.0RC2
PHP Bug Type: Scripting Engine problem
Bug description: Paamayim Nekudotayim on class variables
Description:
just look @ the code
Reproduce code:
---
b = new B;
}
}
class B {
const text = "Hello World";
}
$a = new A;
var_dump($a);
var_dump($a->b);
var_dump($a->b::text); // Error
var_dump(($a->b)::text);// Error
$b = $a->b;
var_dump($b::text); // Works
?>
--
Edit bug report at http://bugs.php.net/?id=48261&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48261&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48261&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48261&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48261&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48261&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48261&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48261&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48261&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48261&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48261&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48261&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48261&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48261&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48261&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48261&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48261&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48261&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48261&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48261&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48261&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48261&r=mysqlcfg
#20298 [Fbk->Opn]: [PATCH] odbc.check_persistent not working
ID: 20298
User updated by: phpbug at tab1 dot clara dot co dot uk
Reported By: phpbug at tab1 dot clara dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: ODBC related
Operating System: *
PHP Version: 5CVS-2004-04-13
New Comment:
That doesn't seem to have fixed it, after killing the connections on
the first reload of the test page I get:
Warning: odbc_exec() [function.odbc-exec]: SQL error: [Microsoft][ODBC
SQL Server Driver][DBNETLIB]ConnectionWrite (send())., SQL state 01000
in SQLExecDirect in C:\InetPub\wwwroot\dbtest.php on line 10
and on the second:
Warning: odbc_exec() [function.odbc-exec]: SQL error: [Microsoft][ODBC
SQL Server Driver]Communication link failure, SQL state 08S01 in
SQLExecDirect in C:\InetPub\wwwroot\dbtest.php on line 10
Previous Comments:
[2009-05-12 02:14:42] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2005-07-27 10:57:57] t-yonetani+php at ergobrains dot co dot jp
Here's a patch written according to phpbugs at kevin dot offwhite dot
net's
suggestion(I hope space and tabs won't be damanged). We're using a
similar
version(just by replacing SQLGetInfo() with SQLGetConnectAttr()) on a
spare
machine, and odbc_pconnect() seems to be working so far. Uncommenting
out
the code for fixing #15758 is a bit scary, but I believe it should be
OK.
Index: php_odbc.c
===
RCS file: /repository/php-src/ext/odbc/php_odbc.c,v
retrieving revision 1.143.2.12
diff -u -r1.143.2.12 php_odbc.c
--- php_odbc.c 14 Jun 2003 03:37:30 - 1.143.2.12
+++ php_odbc.c 27 Jul 2005 08:47:05 -
@@ -2156,6 +2156,29 @@
}
/* }}} */
+/* {{{ is_connection_dead */
+static int is_connection_dead(odbc_connection *db_conn)
+{
+#if defined(HAVE_IBMDB2)
+#else
+ UCHAR d_name[32];
+ SWORD len;
+#endif
+ SQLINTEGER dead;
+ RETCODE ret;
+
+#if defined(HAVE_IBMDB2)
+ ret = SQLGetConnectAttr(db_conn->hdbc, SQL_ATTR_CONNECTION_DEAD,
&dead,
+ 0, NULL);
+#else
+ ret = SQLGetInfo(db_conn->hdbc, SQL_DATA_SOURCE_READ_ONLY, d_name,
+sizeof(d_name), &len);
+ dead = len == 0;
+#endif
+ return ret != SQL_SUCCESS || dead;
+}
+/* }}} */
+
/* Persistent connections: two list-types le_pconn, le_conn and a
plist
* where hashed connection info is stored together with index pointer
to
* the actual link of type le_pconn in the list. Only persistent
@@ -2282,23 +2305,13 @@
* check to see if the connection is still in place
(lurcher)
*/
if(ODBCG(check_persistent)){
- RETCODE ret;
- UCHAR d_name[32];
- SWORD len;
-
- ret = SQLGetInfo(db_conn->hdbc,
- SQL_DATA_SOURCE_READ_ONLY,
- d_name, sizeof(d_name), &len);
-
- if(ret != SQL_SUCCESS || len == 0) {
+ if(is_connection_dead(db_conn)) {
zend_hash_del(&EG(persistent_list),
hashed_details, hashed_len +
1);
- /* Commented out to fix a possible
double closure error
-* when working with persistent
connections as submitted by
-* bug #15758
-*
-* safe_odbc_disconnect(db_conn->hdbc);
-* SQLFreeConnect(db_conn->hdbc);
+ /*
+* now that we know the connection is
dead, just free
+* the DBC handle without issuing
SQLDisconnect().
*/
+ SQLFreeConnect(db_conn->hdbc);
goto try_and_get_another_connection;
}
}
[2004-06-04 22:06:49] phpbugs at kevin dot offwhite dot net
Well, after some additional research I have turned up what I think is
the exact cause of the bug, but I don't feel qualified to implement the
solution.
In the php code, at line 2271 in php_odbc.c (
http://lxr.php.net/source/php-src/ext/odbc/php_odbc.c#2271 ), php calls
SQLGetInfo() passing a parameter of SQL_DATA_SOURCE_READ_ONLY to try and
dete
#37865 [Com]: The SNMP extension does not support setting multiple OIDs
ID: 37865 Comment by: yanirj at orckit dot com Reported By: lee dot duncan at intel dot com Status: Open Bug Type: Feature/Change Request Operating System: SUSE, Kernel 2.6.8-24.21-smp PHP Version: 5.1.4 New Comment: Hi, On behalf of Lee Duncan's good will and Murali Sundar's kindess I've uploaded the patch for everyone to download. I truly hope this will get merged into the CVS tree for everyone to enjoy. URL: http://sphinx.not.nu/php_snmp_patch.zip Regards, Yanir. Previous Comments: [2009-03-17 11:59:59] yanirj at orckit dot com It would be great if you post the patch. Thanks! [2008-05-21 12:21:57] daniel dot buschke at nextiraone dot de Lee, would you please add an attachment with your patch? TIA [2007-03-16 15:11:19] eqguy2002 at yahoo dot com Version: 5.2.1 OS: Windows 2003 PHP's snmpset extension does not support setting multiple OIDs at once. Doing so from the command line using snmpset from Net-SNMP works fine. I need to set multiple OIDs at once in order to manage switches [2006-06-21 00:09:05] lee dot duncan at intel dot com Description: In order to add an entry to many SNMP tables, you need to be able to set multiple OIDs (values) at the same time. The net-snmp "snmpset" command allows this, as do the libnetsnmp APIs, but the SNMP extension to PHP does not support this. I added a new function to ext/snmp.c to support setting multiple values at once, and I'd like to see it added to the PHP SNMP extension for all to use. Reproduce code: --- Just try to set multiple SNMP OIDs (object IDs) with the current API, which is: proto int snmp2_set(string host, string community, string object_id, string type, mixed value [, int timeout [, int retries]]) I added: proto int snmp2_set_arr(string host, string community, array oids, array types, array values [, int timeout [, int retries]]) This way, no current programs break and new programs can use this functionality. Expected result: I'd like to be able to manage things like Marvell switches, which only allow adding a Table entry (e.g. for a new VLAN) if you can set multiple values (OIDs) at the same time. Actual result: -- Right now I can't do this without hacking the PHP SNMP extension. -- Edit this bug report at http://bugs.php.net/?id=37865&edit=1
#48260 [Com]: Size of PHP file affects behaviour of virtual() or #include virtual
ID: 48260 Comment by: p dot tipper at lancaster dot ac dot uk Reported By: p dot tipper at lancaster dot ac dot uk Status: Open Bug Type: Apache2 related Operating System: Debian GNU/Linux 5.0.1 PHP Version: 5.3CVS-2009-05-13 (snap) New Comment: Warning, URLs have gotten wrapped in bug report: Working: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=200 Buggy: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350 etc. Previous Comments: [2009-05-13 11:41:57] p dot tipper at lancaster dot ac dot uk Description: When doing an #include virtual of a php file this seems to change to an include() call (and thus hit basedir restrictions) when the base PHP file reaches a certain size. Also connected with this behaviour is sub-virtual requests also stop working. This seems baffling as this behaviour should occur purely in Apache. Use of virtual() seems to also trigger this bug. Reproduce code: --- This URL works normally: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=200 This URL demonstrates the bug: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350 To see how this is affected by setting open_basedir="/usr/local/lib/php:/tmp:." then check these URLs: Working: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=200&basedir=1 Broken: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350&basedir=1 The "?amount=N" adds more output lines to the main PHP file thus changing its size in an easy manner. All code available from http://red-velvet.lancs.ac.uk:8080/~tipper/include/include-test.tar.gz Expected result: The #include virtual (or virtual()) data should continue to behave as normal, and shouldn't fall foul of basedir restrictions. The following block should always appear at the top of the output: This is an included file /~tipper/include/subdir/test.php Request was /~tipper/include/base/index.php?amount=200 This is an included file /~tipper/include/subdir/test2.php Request was /~tipper/include/base/index.php?amount=200 End of included file /~tipper/include/subdir/test2.php End of included file /~tipper/include/subdir/test.php (Where 200 will be whatever number you set for amount= ) Actual result: -- Once the amount goes above about 340 lines this seems to be the output (from http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350 ) This is an included file /~tipper/include/base/index.php Request was /~tipper/include/base/index.php?amount=350 End of included file /~tipper/include/base/index.php If you try this with open_basedir set to "/usr/local/lib/php:/tmp:." you get the following error (from http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350&basedir=1 ) Warning: main() [function.main]: open_basedir restriction in effect. File(/home/tipper/public_html/include/subdir/test.php) is not within the allowed path(s): (/usr/local/lib/php:/tmp:.) in /home/tipper/public_html/include/base/index.php on line 30 Warning: main(/home/tipper/public_html/include/subdir/test.php) [function.main]: failed to open stream: Operation not permitted in /home/tipper/public_html/include/base/index.php on line 30 Warning: main() [function.include]: Failed opening '/home/tipper/public_html/include/subdir/test.php' for inclusion (include_path='.:/usr/local/lib/php') in /home/tipper/public_html/include/base/index.php on line 30 -- Edit this bug report at http://bugs.php.net/?id=48260&edit=1
#48260 [NEW]: Size of PHP file affects behaviour of virtual() or #include virtual
From: p dot tipper at lancaster dot ac dot uk Operating system: Debian GNU/Linux 5.0.1 PHP version: 5.3CVS-2009-05-13 (snap) PHP Bug Type: Apache2 related Bug description: Size of PHP file affects behaviour of virtual() or #include virtual Description: When doing an #include virtual of a php file this seems to change to an include() call (and thus hit basedir restrictions) when the base PHP file reaches a certain size. Also connected with this behaviour is sub-virtual requests also stop working. This seems baffling as this behaviour should occur purely in Apache. Use of virtual() seems to also trigger this bug. Reproduce code: --- This URL works normally: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=200 This URL demonstrates the bug: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350 To see how this is affected by setting open_basedir="/usr/local/lib/php:/tmp:." then check these URLs: Working: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=200&basedir=1 Broken: http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350&basedir=1 The "?amount=N" adds more output lines to the main PHP file thus changing its size in an easy manner. All code available from http://red-velvet.lancs.ac.uk:8080/~tipper/include/include-test.tar.gz Expected result: The #include virtual (or virtual()) data should continue to behave as normal, and shouldn't fall foul of basedir restrictions. The following block should always appear at the top of the output: This is an included file /~tipper/include/subdir/test.php Request was /~tipper/include/base/index.php?amount=200 This is an included file /~tipper/include/subdir/test2.php Request was /~tipper/include/base/index.php?amount=200 End of included file /~tipper/include/subdir/test2.php End of included file /~tipper/include/subdir/test.php (Where 200 will be whatever number you set for amount= ) Actual result: -- Once the amount goes above about 340 lines this seems to be the output (from http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350 ) This is an included file /~tipper/include/base/index.php Request was /~tipper/include/base/index.php?amount=350 End of included file /~tipper/include/base/index.php If you try this with open_basedir set to "/usr/local/lib/php:/tmp:." you get the following error (from http://red-velvet.lancs.ac.uk:8080/~tipper/include/base/index.php?amount=350&basedir=1 ) Warning: main() [function.main]: open_basedir restriction in effect. File(/home/tipper/public_html/include/subdir/test.php) is not within the allowed path(s): (/usr/local/lib/php:/tmp:.) in /home/tipper/public_html/include/base/index.php on line 30 Warning: main(/home/tipper/public_html/include/subdir/test.php) [function.main]: failed to open stream: Operation not permitted in /home/tipper/public_html/include/base/index.php on line 30 Warning: main() [function.include]: Failed opening '/home/tipper/public_html/include/subdir/test.php' for inclusion (include_path='.:/usr/local/lib/php') in /home/tipper/public_html/include/base/index.php on line 30 -- Edit bug report at http://bugs.php.net/?id=48260&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48260&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48260&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48260&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48260&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48260&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48260&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48260&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48260&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48260&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48260&r=support Expected behavior: http://bugs.php.net/fix.php?id=48260&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48260&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48260&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48260&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48260&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48260&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48260&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48260&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48260&r=float No Zend Extensions: http://bugs.php
#48134 [Fbk->Opn]: php crash after a few days (backtrace attached) with worker MPM
ID: 48134 User updated by: jimbobpalmer at gmail dot com Reported By: jimbobpalmer at gmail dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: * (ZTS only) PHP Version: 5.2.9 New Comment: > Can you just try with prefork MPM so we can make the list of > possible issues a bit shorter..? Prefork has had no segfaults in more than two days, versus 10 hours for the first segfault with the worker mpm (then a mass of segfaults a day or two later). Previous Comments: [2009-05-07 22:42:58] j...@php.net Can you just try with prefork MPM so we can make the list of possible issues a bit shorter..? And yes, supposedly PHP is thread safe, just some libraries might not be and of course there might be bugs in PHP. [2009-05-07 19:08:55] jimbobpalmer at gmail dot com Is php not thread safe? [2009-05-07 14:00:49] j...@php.net That explains it. You propably wouldn't have any problems if you didn't use threaded MPM. Try the more stable prefork MPM instead. [2009-05-07 13:44:47] jimbobpalmer at gmail dot com Worker MPM + apache2handler [2009-05-07 13:19:30] j...@php.net Exactly what MPM are you using and what PHP SAPI module? 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/48134 -- Edit this bug report at http://bugs.php.net/?id=48134&edit=1
#48245 [Opn]: Setting file datetime outside of matching DST settings loses time.
ID: 48245
User updated by: RQuadling at GMail dot com
Reported By: RQuadling at GMail dot com
Status: Open
Bug Type: Date/time related
Operating System: Windows XP SP3
PHP Version: 5.3CVS-2009-05-12 (snap)
New Comment:
If I use the -n option for V5.3 to not use my INI file, I get the
normal notice regarding a lack of timezone settings ...
"It is not safe to rely on the system's timezone settings. You are
*required* to use the date.timezone setting or the
date_default_timezone_set() function. In case you used any of
those methods and you are still getting this warning, you most
likely misspelled the timezone identifier. We selected
'Europe/London' for '1.0/DST'"
date
date/time support => enabled
"Olson" Timezone Database Version => 2009.7
Timezone Database => internal
Default timezone => Europe/London
Directive => Local Value => Master Value
date.default_latitude => 50.3870 => 50.3870
date.default_longitude => -3.9520 => -3.9520
date.sunrise_zenith => 90.58 => 90.58
date.sunset_zenith => 90.58 => 90.58
date.timezone => Europe/London => Europe/London
Previous Comments:
[2009-05-13 08:28:09] RQuadling at GMail dot com
No difference...
>php -n -f z:\testDST.php
PHP V5.2.10-dev OS:WINNT SAPI:cli
Loaded INI:
Wanted to set the date to : (1242216855) 1 Wed, 13 May 2009 13:14:15
+0100
File was set to : (1242216855) 1 Wed, 13 May 2009 13:14:15
+0100
Match
Wanted to set the date to : (1233633906) 0 Tue, 03 Feb 2009 04:05:06
+
File was set to : (1233630306) 0 Tue, 03 Feb 2009 03:05:06
+
Different
Wanted to set the date to : (1222830306) 1 Wed, 01 Oct 2008 04:05:06
+0100
File was set to : (1222830306) 1 Wed, 01 Oct 2008 04:05:06
+0100
Match
and
PHP V5.3.0RC3-dev OS:WINNT SAPI:cli
Loaded INI:D:\PHP\INI\php-cli.ini
Wanted to set the date to : (1242216855) 1 Wed, 13 May 2009 13:14:15
+0100
File was set to : (1242216855) 1 Wed, 13 May 2009 13:14:15
+0100
Match
Wanted to set the date to : (1233633906) 0 Tue, 03 Feb 2009 04:05:06
+
File was set to : (1233630306) 0 Tue, 03 Feb 2009 03:05:06
+
Different
Wanted to set the date to : (1222830306) 1 Wed, 01 Oct 2008 04:05:06
+0100
File was set to : (1222830306) 1 Wed, 01 Oct 2008 04:05:06
+0100
Match
With the latest 5.2 and 5.3 snapshots.
[2009-05-13 00:50:11] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-05-12 14:30:23] RQuadling at GMail dot com
Description:
Touching a file with a non DST datetime and then reading it back is
losing 1 hour.
Using Procmon, Windows is getting and returning the correct times.
It seems that PHP is adjusting the times it gets when in DST and
reading a file NOT in DST.
Reproduce code:
---
strtotime('today 13:14:15'),
'January 1st' => strtotime('2009/02/03 04:05:06'),
'October 1st' => strtotime('2008/10/01 04:05:06'),
);
foreach($a_Dates as $s_When => $dt_Date) {
touch($s_File, $dt_Date);
clearstatcache();
$dt_Modified = filemtime($s_File);
echo
'Wanted to set the date to : (', $dt_Date, ') ', date('r',
$dt_Date), PHP_EOL,
'File was set to : (', $dt_Modified, ') ', date('r',
$dt_Modified), PHP_EOL,
($dt_Date === $dt_Modified ? 'Match' : 'Different'), PHP_EOL,
PHP_EOL;
}
// Clean-up
unlink($s_File);
Expected result:
Wanted to set the date to : (1242130455) Tue, 12 May 2009 13:14:15
+0100
File was set to : (1242130455) Tue, 12 May 2009 13:14:15
+0100
Match
Wanted to set the date to : (1233633906) Tue, 03 Feb 2009 04:05:06
+
File was set to : (1233633906) Tue, 03 Feb 2009 04:05:06
+
Match
Wanted to set the date to : (1222830306) Wed, 01 Oct 2008 04:05:06
+0100
File was set to : (1222830306) Wed, 01 Oct 2008 04:05:06
+0100
Match
Actual result:
--
Wanted to set the date to : (1242130455) Tue, 12 May 2009 13:14:15
+0100
File was set to : (1242130455) Tue, 12 May 2009 13:14:15
+0100
Match
Wanted to set the date to : (1233633906) Tue, 03 Feb 2009 04:05:06
+
File was set to : (1233630306) Tue, 03 Feb 2009 03:05:06
+
Different
Wanted to set the date to : (1222830306) Wed, 01 Oct 2008 04:05:06
+0100
File was set to : (1222830306) Wed, 01 Oct 2008 04:05:06
+0100
Match
--
Edit this bug report at http://bugs.php.net/?id=48245&edit=1
#48245 [Fbk->Opn]: Setting file datetime outside of matching DST settings loses time.
ID: 48245
User updated by: RQuadling at GMail dot com
Reported By: RQuadling at GMail dot com
-Status: Feedback
+Status: Open
Bug Type: Date/time related
Operating System: Windows XP SP3
PHP Version: 5.3CVS-2009-05-12 (snap)
New Comment:
No difference...
>php -n -f z:\testDST.php
PHP V5.2.10-dev OS:WINNT SAPI:cli
Loaded INI:
Wanted to set the date to : (1242216855) 1 Wed, 13 May 2009 13:14:15
+0100
File was set to : (1242216855) 1 Wed, 13 May 2009 13:14:15
+0100
Match
Wanted to set the date to : (1233633906) 0 Tue, 03 Feb 2009 04:05:06
+
File was set to : (1233630306) 0 Tue, 03 Feb 2009 03:05:06
+
Different
Wanted to set the date to : (1222830306) 1 Wed, 01 Oct 2008 04:05:06
+0100
File was set to : (1222830306) 1 Wed, 01 Oct 2008 04:05:06
+0100
Match
and
PHP V5.3.0RC3-dev OS:WINNT SAPI:cli
Loaded INI:D:\PHP\INI\php-cli.ini
Wanted to set the date to : (1242216855) 1 Wed, 13 May 2009 13:14:15
+0100
File was set to : (1242216855) 1 Wed, 13 May 2009 13:14:15
+0100
Match
Wanted to set the date to : (1233633906) 0 Tue, 03 Feb 2009 04:05:06
+
File was set to : (1233630306) 0 Tue, 03 Feb 2009 03:05:06
+
Different
Wanted to set the date to : (1222830306) 1 Wed, 01 Oct 2008 04:05:06
+0100
File was set to : (1222830306) 1 Wed, 01 Oct 2008 04:05:06
+0100
Match
With the latest 5.2 and 5.3 snapshots.
Previous Comments:
[2009-05-13 00:50:11] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-05-12 14:30:23] RQuadling at GMail dot com
Description:
Touching a file with a non DST datetime and then reading it back is
losing 1 hour.
Using Procmon, Windows is getting and returning the correct times.
It seems that PHP is adjusting the times it gets when in DST and
reading a file NOT in DST.
Reproduce code:
---
strtotime('today 13:14:15'),
'January 1st' => strtotime('2009/02/03 04:05:06'),
'October 1st' => strtotime('2008/10/01 04:05:06'),
);
foreach($a_Dates as $s_When => $dt_Date) {
touch($s_File, $dt_Date);
clearstatcache();
$dt_Modified = filemtime($s_File);
echo
'Wanted to set the date to : (', $dt_Date, ') ', date('r',
$dt_Date), PHP_EOL,
'File was set to : (', $dt_Modified, ') ', date('r',
$dt_Modified), PHP_EOL,
($dt_Date === $dt_Modified ? 'Match' : 'Different'), PHP_EOL,
PHP_EOL;
}
// Clean-up
unlink($s_File);
Expected result:
Wanted to set the date to : (1242130455) Tue, 12 May 2009 13:14:15
+0100
File was set to : (1242130455) Tue, 12 May 2009 13:14:15
+0100
Match
Wanted to set the date to : (1233633906) Tue, 03 Feb 2009 04:05:06
+
File was set to : (1233633906) Tue, 03 Feb 2009 04:05:06
+
Match
Wanted to set the date to : (1222830306) Wed, 01 Oct 2008 04:05:06
+0100
File was set to : (1222830306) Wed, 01 Oct 2008 04:05:06
+0100
Match
Actual result:
--
Wanted to set the date to : (1242130455) Tue, 12 May 2009 13:14:15
+0100
File was set to : (1242130455) Tue, 12 May 2009 13:14:15
+0100
Match
Wanted to set the date to : (1233633906) Tue, 03 Feb 2009 04:05:06
+
File was set to : (1233630306) Tue, 03 Feb 2009 03:05:06
+
Different
Wanted to set the date to : (1222830306) Wed, 01 Oct 2008 04:05:06
+0100
File was set to : (1222830306) Wed, 01 Oct 2008 04:05:06
+0100
Match
--
Edit this bug report at http://bugs.php.net/?id=48245&edit=1
#6932 [Com]: Filesize / File_exists and include_path
ID: 6932 Comment by: gw at spamspamspam dot fsnet dot co dot uk Reported By: richard dot heyes at heyes-computing dot net Status: Open Bug Type: Feature/Change Request Operating System: Any PHP Version: 4.0.2 New Comment: Please add bzopen to the list of functions that really should support "use_include_path". Having to code full paths or loop through the include_path manually is amateurish for a language this evolved. :( Previous Comments: [2009-03-06 16:46:41] paul at edunation dot co dot uk This is one of those things that really should be added... Why am I still looping though the include paths? $array = explode(PATH_SEPARATOR, get_include_path()); Come on, let's fix this in under 10 years! [2008-10-29 18:23:00] b_farrell60 at hotmail dot com Ping! This is still important (to me). [2008-06-08 17:44:32] pablo at rauzy dot name This is another request for this feature. This has already been said : __autoload users need this feature ! [2007-02-18 16:36:19] zzarbi at free dot fr Moreover with auload we can't "officialy" get an excepetion so add this parameter to this function is very important !!! [2007-01-26 21:52:20] yarych at ua dot fm This is really needed! Vote for this.. 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/6932 -- Edit this bug report at http://bugs.php.net/?id=6932&edit=1
#48258 [Opn->Fbk]: imap_header crash without any response when to: or cc: is very long
ID: 48258 Updated by: paj...@php.net Reported By: rimgaudas dot laucius at delfi dot lt -Status: Open +Status: Feedback Bug Type: IMAP related Operating System: linux-windows PHP Version: 5.2.9 New Comment: Please install the debug symbols or compile PHP in debug mode. Which c-client do you use? If it is an old version (<2007) please try using 2007e. Previous Comments: [2009-05-13 08:01:40] rimgaudas dot laucius at delfi dot lt Description: failure noticed when "to:" was 14 KB long and another failure noticed when "cc:" was 34 KB long. here stacktrace (with php 5.2.8, but 5.2.9 crash as well): This GDB was configured as "i686-pld-linux"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run imaptest.php Starting program: /usr/bin/php imaptest.php (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1215653088 (LWP 26789)] [New Thread -1232208976 (LWP 26792)] [Thread -1232208976 (zombie) exited] test Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1215653088 (LWP 26789)] 0xb7938afc in memcpy () from /lib/tls/libc.so.6 (gdb) bt #0 0xb7938afc in memcpy () from /lib/tls/libc.so.6 #1 0xb6ed420f in rfc822_skip_comment () from /usr/lib/libc-client.so.2006k #2 0xb6ed4255 in rfc822_skip_comment () from /usr/lib/libc-client.so.2006k #3 0xb6ed4c0b in rfc822_output_address () from /usr/lib/libc-client.so.2006k #4 0xb6ed497d in rfc822_output_address_list () from /usr/lib/libc-client.so.2006k #5 0xb6fac3c2 in zif_imap_mime_header_decode () from /usr/lib/php/imap.so #6 0x0029 in ?? () #7 0x in ?? () (gdb) Quit -- Edit this bug report at http://bugs.php.net/?id=48258&edit=1
#48258 [NEW]: imap_header crash without any response when to: or cc: is very long
From: rimgaudas dot laucius at delfi dot lt Operating system: linux-windows PHP version: 5.2.9 PHP Bug Type: IMAP related Bug description: imap_header crash without any response when to: or cc: is very long Description: failure noticed when "to:" was 14 KB long and another failure noticed when "cc:" was 34 KB long. here stacktrace (with php 5.2.8, but 5.2.9 crash as well): This GDB was configured as "i686-pld-linux"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run imaptest.php Starting program: /usr/bin/php imaptest.php (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1215653088 (LWP 26789)] [New Thread -1232208976 (LWP 26792)] [Thread -1232208976 (zombie) exited] test Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1215653088 (LWP 26789)] 0xb7938afc in memcpy () from /lib/tls/libc.so.6 (gdb) bt #0 0xb7938afc in memcpy () from /lib/tls/libc.so.6 #1 0xb6ed420f in rfc822_skip_comment () from /usr/lib/libc-client.so.2006k #2 0xb6ed4255 in rfc822_skip_comment () from /usr/lib/libc-client.so.2006k #3 0xb6ed4c0b in rfc822_output_address () from /usr/lib/libc-client.so.2006k #4 0xb6ed497d in rfc822_output_address_list () from /usr/lib/libc-client.so.2006k #5 0xb6fac3c2 in zif_imap_mime_header_decode () from /usr/lib/php/imap.so #6 0x0029 in ?? () #7 0x in ?? () (gdb) Quit -- Edit bug report at http://bugs.php.net/?id=48258&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48258&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48258&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48258&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48258&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48258&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48258&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48258&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48258&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48258&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48258&r=support Expected behavior: http://bugs.php.net/fix.php?id=48258&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48258&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48258&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48258&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48258&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48258&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48258&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48258&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48258&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48258&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48258&r=mysqlcfg
#48240 [Csd]: DBA Segmentation fault dba_nextkey
ID: 48240
User updated by: VJTD3 at VJTD3 dot com
Reported By: VJTD3 at VJTD3 dot com
Status: Closed
Bug Type: DBM/DBA related
Operating System: linux redhat fedora 10
PHP Version: 5.2.9
Assigned To: felipe
New Comment:
can this be changed to return the first result if there is one and
false if there are none?
db_firstkey is a rewind, db_nextkey is a iterator. starting from the
beginning makes sense.
Previous Comments:
[2009-05-13 02:17:19] fel...@php.net
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.
Fixed in 5.2, 5.3 and HEAD.
FALSE is returned now.
[2009-05-12 14:31:58] VJTD3 at VJTD3 dot com
[New Thread 0xb7ff56c0 (LWP 10754)]
Program received signal SIGSEGV, Segmentation fault.
0x080d0c66 in dba_nextkey_db4 (info=0x84d75f0, newlen=0xbfffb360)
at php-5.2.9/ext/dba/dba_db4.c:222
222 if (dba->cursor->c_get(dba->cursor, &gkey, &gval,
DB_NEXT) == 0)
{
(gdb) bt
#0 0x080d0c66 in dba_nextkey_db4 (info=0x84d75f0, newlen=0xbfffb360)
at php-5.2.9/ext/dba/dba_db4.c:222
#1 0x080cf3cc in zif_dba_nextkey (ht=1, return_value=0x84d6e78,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at php-5.2.9/ext/dba/dba.c:1101
#2 0x08304280 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffb548)
at php-5.2.9/Zend/zend_vm_execute.h:200
#3 0x08309bba in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbfffb548)
at php-5.2.9/Zend/zend_vm_execute.h:1729
#4 0x08303dfd in execute (op_array=0x84d7538)
at php-5.2.9/Zend/zend_vm_execute.h:92
#5 0x082df04e in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at php-5.2.9/Zend/zend.c:1134
#6 0x0828dd81 in php_execute_script (primary_file=0xbfffd8c4)
at php-5.2.9/main/main.c:2023
#7 0x0835a851 in main (argc=2, argv=0xbfffda04)
at php-5.2.9/sapi/cli/php_cli.c:1133
(gdb) frame 0
#0 0x080d0c66 in dba_nextkey_db4 (info=0x84d75f0, newlen=0xbfffb360)
at php-5.2.9/ext/dba/dba_db4.c:222
222 if (dba->cursor->c_get(dba->cursor, &gkey, &gval,
DB_NEXT) == 0)
{
(gdb) frame 1
#1 0x080cf3cc in zif_dba_nextkey (ht=1, return_value=0x84d6e78,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at php-5.2.9/ext/dba/dba.c:1101
1101nkey = info->hnd->nextkey(info, &len TSRMLS_CC);
(gdb) frame 2
#2 0x08304280 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffb548)
at php-5.2.9/Zend/zend_vm_execute.h:200
200 ((zend_internal_function *)
EX(function_state).f
unction)->handler(opline->extended_value,
EX_T(opline->result.u.var).var.ptr, EX
(function_state).function->common.return_reference?&EX_T(opline->result.u.var).v
ar.ptr:NULL, EX(object), return_value_used TSRMLS_CC);
(gdb) frame 3
#3 0x08309bba in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbfffb548)
at php-5.2.9/Zend/zend_vm_execute.h:1729
1729return
zend_do_fcall_common_helper_SPEC(ZEND_OPCODE_HANDLER_ARGS
_PASSTHRU);
(gdb) frame 4
#4 0x08303dfd in execute (op_array=0x84d7538)
at php-5.2.9/Zend/zend_vm_execute.h:92
92 if (EX(opline)->handler(&execute_data
TSRMLS_CC) > 0) {
(gdb) frame 5
#5 0x082df04e in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at php-5.2.9/Zend/zend.c:1134
1134zend_execute(EG(active_op_array)
TSRMLS_CC);
(gdb) frame 6
#6 0x0828dd81 in php_execute_script (primary_file=0xbfffd8c4)
at php-5.2.9/main/main.c:2023
2023retval = (zend_execute_scripts(ZEND_REQUIRE
TSRMLS_CC, N
ULL, 3, prepend_file_p, primary_file, append_file_p) ==
SUCCESS);
(gdb) frame 7
#7 0x0835a851 in main (argc=2, argv=0xbfffda04)
at php-5.2.9/sapi/cli/php_cli.c:1133
1133php_execute_script(&file_handle
TSRMLS_CC);
(gdb)
if you need me to go into more i can. it looks like it's just
referencing a value not set till dba_firstkey is called. (does not have
a previous index to find the next.)
[2009-05-12 13:30:59] VJTD3 at VJTD3 dot com
that alone will seg fault. it'
#48247 [Fbk->Opn]: PHP crashes on errors during startup
ID: 48247 User updated by: dmi...@php.net Reported By: dmi...@php.net -Status: Feedback +Status: Open Bug Type: Date/time related Operating System: * PHP Version: 5.*, 6CVS (2009-05-12) Assigned To: jani New Comment: Unfortunately this patch doesn't fix the bug. Previous Comments: [2009-05-13 00:46:26] j...@php.net Dmitry, I committed a fix in HEAD. Please check it out. If you agree, I'll MFH to other branches. [2009-05-12 17:11:00] j...@php.net And of course this problem exists in all branches. [2009-05-12 16:31:46] j...@php.net See also bug #37111 which is similar problem, just during shutdown. [2009-05-12 16:09:53] dmi...@php.net Description: PHP crashes in case of warning messages during MINIT(). In case of warning messages during MINIT() the php_log_err() function is called. In case error_log directive is set to log errors into file this function tries to add timestamp using formatting through php_format_date(). However it leads PHP into infinity recursion if TZ isn't set, because php_format_date() throws another warning. Even preventing the recursion with static flag makes PHP crash in ext/date because of uninitialized DATEG(tzcache). #0 0x084922d2 in zend_hash_find (ht=0x89e9ac8, arKey=0x857edbd "Europe/Moscow", nKeyLength=14, pData=0xceac) at /home/dmitry/php/php5.3/Zend/zend_hash.c:880 #1 0x08142ff1 in php_date_parse_tzfile ( formal_tzname=0x857edbd "Europe/Moscow", tzdb=0x85cb9c8) at /home/dmitry/php/php5.3/ext/date/php_date.c:813 #2 0x081432a9 in get_timezone_info () at /home/dmitry/php/php5.3/ext/date/php_date.c:917 #3 0x08144d8c in php_format_date (format=0x899b203 "d-M-Y H:i:s", format_len=11, ts=1242143549, localtime=1) at /home/dmitry/php/php5.3/ext/date/php_date.c:1166 #4 0x08415f16 in php_log_err ( log_message=0xf7f8f678 "PHP Warning: test in Unknown on line 0") at /home/dmitry/php/php5.3/main/main.c:547 #5 0x08416db9 in php_error_cb (type=2, error_filename=0x89b00cf "Unknown", error_lineno=0, format=0x899bb97 "test", args=0xd088 "\005") at /home/dmitry/php/php5.3/main/main.c:958 #6 0x084832d2 in zend_error (type=2, format=0x899bb97 "test") at /home/dmitry/php/php5.3/Zend/zend.c:1020 #7 0x08418ecf in php_module_startup (sf=0x89d11a0, additional_modules=0x0, num_additional_modules=0) at /home/dmitry/php/php5.3/main/main.c:2021 #8 0x08546f59 in php_cli_startup (sapi_module=0x89d11a0) at /home/dmitry/php/php5.3/sapi/cli/php_cli.c:399 -- Edit this bug report at http://bugs.php.net/?id=48247&edit=1
