#47828 [Opn]: Seg Fault in openssl_x509_parse
ID: 47828 Updated by: paj...@php.net Reported By: reinke at securityspace dot com Status: Open Bug Type: OpenSSL related Operating System: Linux (Debian Lenny) PHP Version: 5.2.9 Assigned To: pajoye New Comment: With all due respect - we are using PHP's official release. On Debian. As provided by the distro. On Ubuntu. As provided by Ubuntu. On Fedora. As provided by... well, you get it. Like it or not, these vendors are your distribution channel No, our official distributions channel is http://www.php.net/downloads and http://windows.php.net, nothing else. Distributions, in their majority, do a great job at distributing php but they are not our official releases channel, especially not when they use unofficial patches like suhosin or other random changes. The reason we ask to try PHP's version is to be sure about the src of the problem, we have no control over what the distros do or don't. Previous Comments: [2009-03-30 05:52:22] paj...@php.net Scott, that's nice but add a test please with the data you use to reproduce the segfault. [2009-03-29 23:45:51] scott...@php.net I fixed it about 10 minutes ago, the snapshot is from a few hours ago. [2009-03-29 23:38:46] reinke at securityspace dot com Also reproduced on Lenny using snapshot php5.2-200903292230. ./configure --with-openssl make sapi/cli/php ~/core2.php - segmentation fault. [2009-03-29 23:33:40] scott...@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. The string tried to decode one of the items to utf-8 and it failed, this wasn't properly checked resulting in a segfault. [2009-03-29 22:29:26] reinke at securityspace dot com With all due respect - we are using PHP's official release. On Debian. As provided by the distro. On Ubuntu. As provided by Ubuntu. On Fedora. As provided by... well, you get it. Like it or not, these vendors are your distribution channel, and what they provide IS defacto your official release. Simply by virtue of the fact that most people are using that channel for getting their binary version of PHP. If you are asking us to help TEST the bug, fine - that's not a problem. If you are suggesting what I think you suggested, that is upgrading to your official off the www.php.net web site release to solve the problem, that's not happening, for a large variety of reasons. Nor will it happen for a LOT of other users, either. FWIW - on a Fedora Core 10 system, fully updated, your snapshot (php5.2-200903292030) configured and compiled with ./configure --with-openssl make reproduces the problem. 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/47828 -- Edit this bug report at http://bugs.php.net/?id=47828edit=1
#47835 [Opn-Bgs]: strtotime or date works wrong
ID: 47835
Updated by: der...@php.net
Reported By: snowyurik at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Linux
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.
This is also expected behavior, remember that there is no February
30th!
Previous Comments:
[2009-03-30 04:00:12] snowyurik at gmail dot com
Description:
echo date('Y-m-d H:i:s',strtotime('2009-02-30 00:00:00'));
this code return
2009-03-02 00:00:00 instead of 2009-02-30 00:00:00
Reproduce code:
---
echo date('Y-m-d H:i:s',strtotime('2009-02-30 00:00:00'));
Expected result:
2009-02-30 00:00:00
--
Edit this bug report at http://bugs.php.net/?id=47835edit=1
#47836 [NEW]: array operator [] has inconsistency when the array has PHP_MAX_INT index value.
From: for-bugs at hnw dot jp
Operating system: *
PHP version: 5.2.9
PHP Bug Type: Arrays related
Bug description: array operator [] has inconsistency when the array has
PHP_MAX_INT index value.
Description:
The behavior of operator [] to the array is sometimes strange or hard to
describe the specification. For instance, the array which has two index,
2147483647 and -2147483648 on 32bit environment gets strange results. See
below example:
Reproduce code:
---
?php
$array=array();
$array[-2147483648]=2;
$array[2147483647]=1;
$array[]=3;
var_dump($array);
$array=array();
$array[2147483647]=1;
$array[-2147483648]=2;
$array[]=3;
var_dump($array);
Expected result:
It should be same behavior. I think, the substitution to $array[] shuold
be both failed for this case.
Actual result:
--
PHP Warning: Cannot add element to the array as the next element is
already occupied in ./array-maxint-test.php on line 5
array(2) {
[-2147483648]=
int(2)
[2147483647]=
int(1)
}
array(3) {
[2147483647]=
int(1)
[-2147483648]=
int(2)
[-2147483647]=
int(3)
}
--
Edit bug report at http://bugs.php.net/?id=47836edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47836r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47836r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47836r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47836r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47836r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47836r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47836r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47836r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47836r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47836r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47836r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47836r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47836r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47836r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47836r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47836r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47836r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47836r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47836r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47836r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47836r=mysqlcfg
#47828 [Opn]: Seg Fault in openssl_x509_parse
ID: 47828 Updated by: scott...@php.net Reported By: reinke at securityspace dot com Status: Open Bug Type: OpenSSL related Operating System: Linux (Debian Lenny) PHP Version: 5.2.9 -Assigned To: pajoye +Assigned To: scottmac New Comment: Pierre using the test given by the reporter I could reproduce this, took less than a minute to find the issue. Assigning yourself a bug that you'll look at next week isn't all that useful, especially if someone with more time comes along in that next week. Perhaps we need to add multiple assignment to bugs? FYI OpenSSL verions OpenSSL 0.9.7l 28 Sep 2006 (OS X default) OpenSSL 0.9.8j 07 Jan 2009 Previous Comments: [2009-03-30 06:00:06] paj...@php.net With all due respect - we are using PHP's official release. On Debian. As provided by the distro. On Ubuntu. As provided by Ubuntu. On Fedora. As provided by... well, you get it. Like it or not, these vendors are your distribution channel No, our official distributions channel is http://www.php.net/downloads and http://windows.php.net, nothing else. Distributions, in their majority, do a great job at distributing php but they are not our official releases channel, especially not when they use unofficial patches like suhosin or other random changes. The reason we ask to try PHP's version is to be sure about the src of the problem, we have no control over what the distros do or don't. [2009-03-30 05:52:22] paj...@php.net Scott, that's nice but add a test please with the data you use to reproduce the segfault. [2009-03-29 23:45:51] scott...@php.net I fixed it about 10 minutes ago, the snapshot is from a few hours ago. [2009-03-29 23:38:46] reinke at securityspace dot com Also reproduced on Lenny using snapshot php5.2-200903292230. ./configure --with-openssl make sapi/cli/php ~/core2.php - segmentation fault. [2009-03-29 23:33:40] scott...@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. The string tried to decode one of the items to utf-8 and it failed, this wasn't properly checked resulting in a segfault. 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/47828 -- Edit this bug report at http://bugs.php.net/?id=47828edit=1
#47828 [Opn-Csd]: Seg Fault in openssl_x509_parse
ID: 47828 Updated by: scott...@php.net Reported By: reinke at securityspace dot com -Status: Open +Status: Closed Bug Type: OpenSSL related Operating System: Linux (Debian Lenny) PHP Version: 5.2.9 Assigned To: scottmac Previous Comments: [2009-03-30 09:24:43] scott...@php.net Pierre using the test given by the reporter I could reproduce this, took less than a minute to find the issue. Assigning yourself a bug that you'll look at next week isn't all that useful, especially if someone with more time comes along in that next week. Perhaps we need to add multiple assignment to bugs? FYI OpenSSL verions OpenSSL 0.9.7l 28 Sep 2006 (OS X default) OpenSSL 0.9.8j 07 Jan 2009 [2009-03-30 06:00:06] paj...@php.net With all due respect - we are using PHP's official release. On Debian. As provided by the distro. On Ubuntu. As provided by Ubuntu. On Fedora. As provided by... well, you get it. Like it or not, these vendors are your distribution channel No, our official distributions channel is http://www.php.net/downloads and http://windows.php.net, nothing else. Distributions, in their majority, do a great job at distributing php but they are not our official releases channel, especially not when they use unofficial patches like suhosin or other random changes. The reason we ask to try PHP's version is to be sure about the src of the problem, we have no control over what the distros do or don't. [2009-03-30 05:52:22] paj...@php.net Scott, that's nice but add a test please with the data you use to reproduce the segfault. [2009-03-29 23:45:51] scott...@php.net I fixed it about 10 minutes ago, the snapshot is from a few hours ago. [2009-03-29 23:38:46] reinke at securityspace dot com Also reproduced on Lenny using snapshot php5.2-200903292230. ./configure --with-openssl make sapi/cli/php ~/core2.php - segmentation fault. 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/47828 -- Edit this bug report at http://bugs.php.net/?id=47828edit=1
#47828 [Csd]: Seg Fault in openssl_x509_parse
ID: 47828 Updated by: paj...@php.net Reported By: reinke at securityspace dot com Status: Closed Bug Type: OpenSSL related Operating System: Linux (Debian Lenny) PHP Version: 5.2.9 Assigned To: scottmac New Comment: Firt, I do not care if it took 0.5 second or 3 hours. Secondly, the bug is less than a day old, we did run test and it did not crash on all platforms I can test (windows, ubuntu x64/x86 and debian). So not it was not obvious that there was a real bug in the current code. And finally, you can't know if a) there is already a patch or a fix and b) what's the status, simply because you did not bother to ask. There is no problem to take over any bug as long as you simply ask before. It will save us time and pains (as in this kind of discussions, which happen only with you). Thanks for your understanding and your work. Previous Comments: [2009-03-30 09:24:43] scott...@php.net Pierre using the test given by the reporter I could reproduce this, took less than a minute to find the issue. Assigning yourself a bug that you'll look at next week isn't all that useful, especially if someone with more time comes along in that next week. Perhaps we need to add multiple assignment to bugs? FYI OpenSSL verions OpenSSL 0.9.7l 28 Sep 2006 (OS X default) OpenSSL 0.9.8j 07 Jan 2009 [2009-03-30 06:00:06] paj...@php.net With all due respect - we are using PHP's official release. On Debian. As provided by the distro. On Ubuntu. As provided by Ubuntu. On Fedora. As provided by... well, you get it. Like it or not, these vendors are your distribution channel No, our official distributions channel is http://www.php.net/downloads and http://windows.php.net, nothing else. Distributions, in their majority, do a great job at distributing php but they are not our official releases channel, especially not when they use unofficial patches like suhosin or other random changes. The reason we ask to try PHP's version is to be sure about the src of the problem, we have no control over what the distros do or don't. [2009-03-30 05:52:22] paj...@php.net Scott, that's nice but add a test please with the data you use to reproduce the segfault. [2009-03-29 23:45:51] scott...@php.net I fixed it about 10 minutes ago, the snapshot is from a few hours ago. [2009-03-29 23:38:46] reinke at securityspace dot com Also reproduced on Lenny using snapshot php5.2-200903292230. ./configure --with-openssl make sapi/cli/php ~/core2.php - segmentation fault. 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/47828 -- Edit this bug report at http://bugs.php.net/?id=47828edit=1
#47832 [Opn-Asn]: Garbled associative array indices
ID: 47832
Updated by: johan...@php.net
Reported By: r dot borschel at gmx dot net
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: OS X 10.5.6
PHP Version: 5.3CVS-2009-03-29 (snap)
-Assigned To:
+Assigned To: mysql
Previous Comments:
[2009-03-29 20:19:46] r dot borschel at gmx dot net
The INSERT statement should of course read:
INSERT INTO `testdb`.`cms_users` (
`id` ,
`status` ,
`username` ,
`name`
) VALUES (NULL , 'developer', 'romanb', 'Roman');
[2009-03-29 20:17:04] r dot borschel at gmx dot net
Description:
Associative array indices are getting garbled when usind pdo_mysql when
mysql pdo_mysql were compiled against libmysql. Compiling against
mysqlnd fixes the issue.
Reproduce code:
---
#
# SQL
#
CREATE TABLE IF NOT EXISTS `cms_users` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`status` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
`username` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
`name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
INSERT INTO `doctrinetests`.`cms_users` (
`id` ,
`status` ,
`username` ,
`name`
) VALUES (NULL , 'developer', 'romanb', 'Roman');
#
# PHP
#
$pdo = new PDO(mysql:host=localhost;dbname=testdb, xxx, xxx);
$stmt = $pdo-prepare(SELECT c0.id AS c0__id, c0.status AS c0__status,
c0.username AS c0__username, c0.name AS c0__name FROM cms_users c0);
$stmt-execute();
while ($data = $stmt-fetch(PDO::FETCH_ASSOC)) {
var_dump($data);
}
Expected result:
array(6) {
[c0__id]= string(2) 16
[c0__status]= string(9) developer
[c0__username]= string(6) romanb
[c0__name]= string(5) Roman
}
Actual result:
--
array(6) {
[c0__id]= string(2) 16
[status]= string(9) developer
[c0]= string(6) romanb
[cms_users]= string(5) Roman
}
--
Edit this bug report at http://bugs.php.net/?id=47832edit=1
#47836 [Opn]: array operator [] has inconsistency when the array has PHP_MAX_INT index value.
ID: 47836
Updated by: matt...@php.net
Reported By: for-bugs at hnw dot jp
Status: Open
Bug Type: Arrays related
Operating System: *
PHP Version: 5.2.9
New Comment:
Untested, but it seems like this would give the expected result. In
zend_hash.c:_zend_hash_index_update_or_next_insert(), change the check
from
if ((long)h = (long)ht-nNextFreeElement) {
ht-nNextFreeElement = h + 1;
}
to
if (h = ht-nNextFreeElement h LONG_MAX) {
ht-nNextFreeElement = h + 1;
}
Previous Comments:
[2009-03-30 07:40:48] for-bugs at hnw dot jp
Description:
The behavior of operator [] to the array is sometimes strange or hard
to describe the specification. For instance, the array which has two
index, 2147483647 and -2147483648 on 32bit environment gets strange
results. See below example:
Reproduce code:
---
?php
$array=array();
$array[-2147483648]=2;
$array[2147483647]=1;
$array[]=3;
var_dump($array);
$array=array();
$array[2147483647]=1;
$array[-2147483648]=2;
$array[]=3;
var_dump($array);
Expected result:
It should be same behavior. I think, the substitution to $array[]
shuold be both failed for this case.
Actual result:
--
PHP Warning: Cannot add element to the array as the next element is
already occupied in ./array-maxint-test.php on line 5
array(2) {
[-2147483648]=
int(2)
[2147483647]=
int(1)
}
array(3) {
[2147483647]=
int(1)
[-2147483648]=
int(2)
[-2147483647]=
int(3)
}
--
Edit this bug report at http://bugs.php.net/?id=47836edit=1
#47819 [Asn-Fbk]: Getting pdo_mysql.so: undefined symbol: mysqlnd_debug_init at startup
ID: 47819 Updated by: johan...@php.net Reported By: shahar dot e at zend dot com -Status: Assigned +Status: Feedback Bug Type: PDO related Operating System: Linux i386 PHP Version: 5.3.0RC1 Assigned To: mysql New Comment: Are you loading the module into a PHP which has mysqlnd enabled? Usually mysqlnd is automatically activated once another extension using mysqlnd is being activated. I tried the following which worked: $ ./configure --disable-all --enable-pdo --with-pdo-mysql=shared,mysqlnd $ make $ sapi/cli/php -d extension_dir=modules/ -d extension=pdo_mysql.so -m Previous Comments: [2009-03-28 10:19:36] shahar dot e at zend dot com Description: I'm putting this under PDO even though this is probably a mysqlnd/build issue. I've compiled PHP5.3.0-RC1 with --enable-debug and --enable-pdo-mysql=mysqlnd,shared. When I try to load the PDO MySQL extension I get this: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/debug-non-zts-20090115/pdo_mysql.so' - /usr/local/lib/php/extensions/debug-non-zts-20090115/pdo_mysql.so: undefined symbol: mysqlnd_debug_init in Unknown on line 0 Some info: PHP Version = 5.3.0RC1 System = Linux wintergreen 2.6.28-gentoo-r2 #1 PREEMPT Sun Mar 8 17:10:56 IST 2009 i686 Build Date = Mar 27 2009 14:37:12 Configure Command = './configure' '--prefix=/usr/local' '--with-apxs2' '--enable-debug' '--with-openssl' '--with-pcre-regex' '--with-zlib' '--enable-bcmath=shared' '--with-bz2=shared' '--enable-calendar=shared' '--with-curl=shared' '--with-enchant=shared' '--enable-exif=shared' '--enable-ftp=shared' '--with-gd=shared' '--with-t 1lib' '--enable-gd-native-ttf' '--with-gettext=shared' '--enable-intl=shared' '--enable-mbstring=shared' '--with-mcrypt=shared' '--with-mysql=shared,mysqlnd' '--with- mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=shared,mysqlnd' '--enable-pcntl=shared' '--with-pdo-mysql=shared,mysqlnd' '--with-pdo-sqlite' '--with-readline' '--enable-soap=shared' '--enable-sockets=shared' '--enable-sqlite-utf8' '--with-tidy=shared' '--enable-zip=shared' '--with-pear' -- Edit this bug report at http://bugs.php.net/?id=47819edit=1
#47811 [Com]: preg_match that can cause segmentation fault
ID: 47811
Comment by: scope at planetavent dot de
Reported By: travis at wikihow dot com
Status: Open
Bug Type: Reproducible crash
Operating System: CentOS release 4.4 Mac OS 10.4
PHP Version: 5.2.9
New Comment:
Here's another snippet:
?php
$s =
XX;
$pattern = @(X)*@;
$return = preg_match( $pattern, $s );
echo $return;
?
This one crashes apache 2.2.8 and 2.2.11 with php-5.2.9 and php-5.2.9-1
on windows 2003.
Previous Comments:
[2009-03-27 23:53:44] dennis dot birkholz at nexxes dot net
I have a similar segfault testcase for preg_match. It always crashes at
a stringlength of around 6700. PHP is 5.2.8 on gentoo linux.
# Create my test-string
for ($i=0; $i2; $i++) {
$string .= 'a';
}
# The pattern matches for \\, \, everything except and
$pattern = '/^(|\\|[^]|)+$/';
print Trying with string length . \033 . '[s';
for ($counter=6600; $counterstrlen($string); $counter++) {
if (preg_match($pattern, substr($string,0,$counter), $matches)) {
print \033 . '[u' . $counter . '...';
flush();
list($dummy, $aa) = $matches;
}
}
print \n;
[2009-03-27 17:26:38] travis at wikihow dot com
Description:
Run a preg_match with source text attached and get a seg fault. Apache
2.2 / PHP 5.2.9 and PHP 5.2.4.
preg_match('@object(.|\n)*/object@im', $text, $matches);
Reproduce code:
---
http://wikidiy.com/php_bug_crash.txt
Expected result:
Apache not supposed to crash, completes preg_match, dumps $matches
array.
Actual result:
--
Apache seg faults
[Fri Mar 27 12:16:05 2009] [notice] child pid 6391 exit signal
Segmentation fault (11)
--
Edit this bug report at http://bugs.php.net/?id=47811edit=1
#47545 [Com]: compile fails: cannot find -lintl
ID: 47545 Comment by: gbpzi at hotmail dot com Reported By: hackert at vin-loesungen dot de Status: Analyzed Bug Type: Sybase-ct (ctlib) related Operating System: Suse Linux 9 PHP Version: 5.2.9 Assigned To: thekid New Comment: /usr/bin/ld: cannot find -lltdl collect2: ld returned 1 exit status make: *** [libphp5.la] Error 1 ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql=/usr/local/mysql-5.1.32-linux-i686-glibc23 --with-mcrypt=/usr/local/mcrrypt-mcrypt-2.6.8 --with-mhash=/usr/local/mhash-0.9.9.9 --enable-mbstring Previous Comments: [2009-03-10 07:46:46] the...@php.net I don't have any Linux setup to test with, but this is probably the same or similar to Bug #45393. [2009-03-05 01:34:43] fel...@php.net Assigned to maintainer. [2009-03-02 15:33:50] hackert at vin-loesungen dot de Description: Hi, when running make after successfull configure --prefix=/usr --disable-all --disable-cgi --with-apxs2=/usr/sbin/apxs2-prefork --with-sybase-ct=/var/opt/sybase/OCS_15-0 the compile-process stops with /bin/sh /root/php/php-5.2.9/libtool --silent --preserve-dup-deps --mode=link gcc -g -O2 -rpath /root/php/php-5.2.9/libs -avoid-version -module -L/var/opt/sybase/OCS-15_0/lib -R /var/opt/sybase/OCS-15_0/lib ext/date/php_date.lo ext/date/lib/astro.lo ext/date/lib/dow.lo ext/date/lib/parse_date.lo ext/date/lib/parse_tz.lo ext/date/lib/timelib.lo ext/date/lib/tm2unixtime.lo ext/date/lib/unixtime2tm.lo ext/reflection/php_reflection.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard/strnatcmp.lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo ext/standard/css.lo ext/standard/var_unserializer.lo ext/standard/ftok.lo ext/standard/sha1.lo ext/standard/user_filters.lo ext/standard/uuencode.lo ext/standard/filters.lo ext/standard/proc_open.lo ext/standard/streamsfuncs.lo ext/standard/http.lo ext/sybase_ct/php_sybase_ct.lo TSRM/TSRM.lo TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo main/fopen_wrappers.lo main/alloca.lo main/php_scandir.lo main/php_ini.lo main/SAPI.lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo main/strlcat.lo main/mergesort.lo main/reentrancy.lo main/php_variables.lo main/php_ticks.lo main/network.lo main/php_open_temporary_file.lo main/php_logos.lo main/output.lo main/streams/streams.lo main/streams/cast.lo main/streams/memory.lo main/streams/filter.lo main/streams/plain_wrapper.lo main/streams/userspace.lo main/streams/transports.lo main/streams/xp_socket.lo main/streams/mmap.lo Zend/zend_language_parser.lo Zend/zend_language_scanner.lo Zend/zend_ini_parser.lo Zend/zend_ini_scanner.lo Zend/zend_alloc.lo Zend/zend_compile.lo Zend/zend_constants.lo Zend/zend_dynamic_array.lo Zend/zend_execute_API.lo Zend/zend_highlight.lo Zend/zend_llist.lo Zend/zend_opcode.lo Zend/zend_operators.lo Zend/zend_ptr_stack.lo Zend/zend_stack.lo Zend/zend_variables.lo Zend/zend.lo Zend/zend_API.lo Zend/zend_extensions.lo Zend/zend_hash.lo Zend/zend_list.lo Zend/zend_indent.lo Zend/zend_builtin_functions.lo Zend/zend_sprintf.lo Zend/zend_ini.lo Zend/zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_ts_hash.lo Zend/zend_stream.lo Zend/zend_iterators.lo Zend/zend_interfaces.lo Zend/zend_exceptions.lo Zend/zend_strtod.lo Zend/zend_objects.lo Zend/zend_object_handlers.lo Zend/zend_objects_API.lo Zend/zend_default_classes.lo Zend/zend_execute.lo sapi/apache2handler/mod_php5.lo
#47832 [Asn-Fbk]: Garbled associative array indices
ID: 47832
Updated by: johan...@php.net
Reported By: r dot borschel at gmx dot net
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: OS X 10.5.6
PHP Version: 5.3CVS-2009-03-29 (snap)
Assigned To: mysql
New Comment:
Which MySQL server and client library versions are you using? - I
tested using 5.1.31 worked for me:
$ sapi/cli/php --ri pdo_mysql
pdo_mysql
PDO Driver for MySQL = enabled
Client API version = 5.1.31
$ sapi/cli/php bug47832.php
array(4) {
[c0__id]=
string(1) 1
[c0__status]=
string(9) developer
[c0__username]=
string(6) romanb
[c0__name]=
string(5) Roman
}
Previous Comments:
[2009-03-29 20:19:46] r dot borschel at gmx dot net
The INSERT statement should of course read:
INSERT INTO `testdb`.`cms_users` (
`id` ,
`status` ,
`username` ,
`name`
) VALUES (NULL , 'developer', 'romanb', 'Roman');
[2009-03-29 20:17:04] r dot borschel at gmx dot net
Description:
Associative array indices are getting garbled when usind pdo_mysql when
mysql pdo_mysql were compiled against libmysql. Compiling against
mysqlnd fixes the issue.
Reproduce code:
---
#
# SQL
#
CREATE TABLE IF NOT EXISTS `cms_users` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`status` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
`username` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
`name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
INSERT INTO `doctrinetests`.`cms_users` (
`id` ,
`status` ,
`username` ,
`name`
) VALUES (NULL , 'developer', 'romanb', 'Roman');
#
# PHP
#
$pdo = new PDO(mysql:host=localhost;dbname=testdb, xxx, xxx);
$stmt = $pdo-prepare(SELECT c0.id AS c0__id, c0.status AS c0__status,
c0.username AS c0__username, c0.name AS c0__name FROM cms_users c0);
$stmt-execute();
while ($data = $stmt-fetch(PDO::FETCH_ASSOC)) {
var_dump($data);
}
Expected result:
array(6) {
[c0__id]= string(2) 16
[c0__status]= string(9) developer
[c0__username]= string(6) romanb
[c0__name]= string(5) Roman
}
Actual result:
--
array(6) {
[c0__id]= string(2) 16
[status]= string(9) developer
[c0]= string(6) romanb
[cms_users]= string(5) Roman
}
--
Edit this bug report at http://bugs.php.net/?id=47832edit=1
#47811 [Opn-Asn]: preg_match that can cause segmentation fault
ID: 47811
Updated by: paj...@php.net
Reported By: travis at wikihow dot com
-Status: Open
+Status: Assigned
Bug Type: Reproducible crash
Operating System: CentOS release 4.4 Mac OS 10.4
PHP Version: 5.2.9
-Assigned To:
+Assigned To: nlopess
New Comment:
Nuno, can you take a look please? Can reproduce it here too.
Previous Comments:
[2009-03-30 11:24:40] scope at planetavent dot de
Here's another snippet:
?php
$s =
XX;
$pattern = @(X)*@;
$return = preg_match( $pattern, $s );
echo $return;
?
This one crashes apache 2.2.8 and 2.2.11 with php-5.2.9 and php-5.2.9-1
on windows 2003.
[2009-03-27 23:53:44] dennis dot birkholz at nexxes dot net
I have a similar segfault testcase for preg_match. It always crashes at
a stringlength of around 6700. PHP is 5.2.8 on gentoo linux.
# Create my test-string
for ($i=0; $i2; $i++) {
$string .= 'a';
}
# The pattern matches for \\, \, everything except and
$pattern = '/^(|\\|[^]|)+$/';
print Trying with string length . \033 . '[s';
for ($counter=6600; $counterstrlen($string); $counter++) {
if (preg_match($pattern, substr($string,0,$counter), $matches)) {
print \033 . '[u' . $counter . '...';
flush();
list($dummy, $aa) = $matches;
}
}
print \n;
[2009-03-27 17:26:38] travis at wikihow dot com
Description:
Run a preg_match with source text attached and get a seg fault. Apache
2.2 / PHP 5.2.9 and PHP 5.2.4.
preg_match('@object(.|\n)*/object@im', $text, $matches);
Reproduce code:
---
http://wikidiy.com/php_bug_crash.txt
Expected result:
Apache not supposed to crash, completes preg_match, dumps $matches
array.
Actual result:
--
Apache seg faults
[Fri Mar 27 12:16:05 2009] [notice] child pid 6391 exit signal
Segmentation fault (11)
--
Edit this bug report at http://bugs.php.net/?id=47811edit=1
#47285 [Com]: strtotime() still leaks memory
ID: 47285
Comment by: kimc at operamail dot com
Reported By: danger at FreeBSD dot org
Status: Assigned
Bug Type: Date/time related
Operating System: FreeBSD
PHP Version: 5.2.8
Assigned To: derick
New Comment:
The last patch fixes the memory leak for me.
Previous Comments:
[2009-03-11 15:36:05] bloudon at townnews dot com
Leak also observed in 5.2.8 and 5.2.9 on Linux.
This patch (against 5.2.9) is working out for us so far in our dev
environment:
--- ext/date/php_date.orig.c2009-03-11 10:07:36.0 -0500
+++ ext/date/php_date.c 2009-03-11 10:12:40.0 -0500
@@ -1108,7 +1108,7 @@
long preset_ts, ts;
timelib_time *t, *now;
- timelib_tzinfo *tzi;
+ timelib_tzinfo *tzi, *old_tzi;
tzi = get_timezone_info(TSRMLS_C);
@@ -1119,10 +1119,14 @@
initial_ts = emalloc(25);
snprintf(initial_ts, 24, @%ld UTC, preset_ts);
t = timelib_strtotime(initial_ts, strlen(initial_ts), NULL,
DATE_TIMEZONEDB); /* we ignore the error here, as this should never fail
*/
+ old_tzi = t-tz_info;
timelib_update_ts(t, tzi);
now-tz_info = tzi;
now-zone_type = TIMELIB_ZONETYPE_ID;
timelib_unixtime2local(now, t-sse);
+ if ( old_tzi ) {
+ timelib_tzinfo_dtor(old_tzi);
+ }
timelib_time_dtor(t);
efree(initial_ts);
} else if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s|l,
times, time_len, preset_ts) != FAILURE) {
@@ -1141,6 +1145,7 @@
}
t = timelib_strtotime(times, time_len, error, DATE_TIMEZONEDB);
+ old_tzi = t-tz_info;
error1 = error-error_count;
timelib_error_container_dtor(error);
timelib_fill_holes(t, now, TIMELIB_NO_CLONE);
@@ -1148,6 +1153,9 @@
ts = timelib_date_to_int(t, error2);
timelib_time_dtor(now);
+ if ( old_tzi ) {
+ timelib_tzinfo_dtor(old_tzi);
+ }
timelib_time_dtor(t);
if (error1 || error2) {
[2009-03-09 21:41:58] martin at 925 dot dk
Removing UTC from the timestamp in php_date.c also fixes the leak:
--- php_date_.c 2009-03-09 22:30:15.0 +0100
+++ php_date.c 2009-03-09 22:30:21.0 +0100
@@ -1117,7 +1117,7 @@
now = timelib_time_ctor();
initial_ts = emalloc(25);
- snprintf(initial_ts, 24, @%ld UTC, preset_ts);
+ snprintf(initial_ts, 24, @%ld, preset_ts);
t = timelib_strtotime(initial_ts, strlen(initial_ts),
NULL, DATE_TIMEZONEDB); /* we ignore the error here, as this should
never fail */
timelib_update_ts(t, tzi);
now-tz_info = tzi;
[2009-03-09 18:46:22] martin at 925 dot dk
This patch (which reverts the fix for bug 45529) against parse_date.c
seems to fix the leak:
Hence this patch against parse_date.c:
--- parse_date_.c 2009-03-09 19:33:37.0 +0100
+++ parse_date.c2009-03-09 19:33:45.0 +0100
@@ -733,7 +733,7 @@
}
#endif
/* If we have a TimeZone identifier to start with, use
it */
- if (strstr(tz_abbr, /) || strcmp(tz_abbr, UTC) ==
0) {
+ if (strstr(tz_abbr, /)) {
if ((res = timelib_parse_tzfile(tz_abbr,
tzdb)) != NULL) {
t-tz_info = res;
t-zone_type = TIMELIB_ZONETYPE_ID;
[2009-02-27 14:48:14] maarten at vivesta dot com
Same here. I've added a date_default_timezone_set() before using
strtotime() and it removed the error but not the leak.
[2009-02-27 13:53:29] danger at FreeBSD dot org
I tried to run my script with php -d error_reporting=E_STRICT test.php
and been receiving this error until I stopped the script:
Strict Standards: strtotime(): It is not safe to rely on the system's
timezone settings. Please use the date.timezone setting, the TZ
environment variable 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/Berlin' for 'CET/1.0/no DST' instead in /root/test.php on line
10
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/47285
--
Edit this bug report at http://bugs.php.net/?id=47285edit=1
#47832 [Fbk-Opn]: Garbled associative array indices
ID: 47832
User updated by: r dot borschel at gmx dot net
Reported By: r dot borschel at gmx dot net
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: OS X 10.5.6
PHP Version: 5.3CVS-2009-03-29 (snap)
Assigned To: mysql
New Comment:
$ sapi/cli/php --ri pdo_mysql
pdo_mysql
PDO Driver for MySQL = enabled
Client API version = 5.0.38
Thats a bit strange, isnt it? My configure looks like this:
'./configure' \
...
'--with-mysql=/usr/local/mysql-5.1.32-osx10.5-x86' \
'--with-pdo-mysql=/usr/local/mysql-5.1.32-osx10.5-x86' \
...
That version mismatch may be the problem? Am I doing something
obviously wrong?
Thanks for your help.
Previous Comments:
[2009-03-30 11:44:41] johan...@php.net
Which MySQL server and client library versions are you using? - I
tested using 5.1.31 worked for me:
$ sapi/cli/php --ri pdo_mysql
pdo_mysql
PDO Driver for MySQL = enabled
Client API version = 5.1.31
$ sapi/cli/php bug47832.php
array(4) {
[c0__id]=
string(1) 1
[c0__status]=
string(9) developer
[c0__username]=
string(6) romanb
[c0__name]=
string(5) Roman
}
[2009-03-29 20:19:46] r dot borschel at gmx dot net
The INSERT statement should of course read:
INSERT INTO `testdb`.`cms_users` (
`id` ,
`status` ,
`username` ,
`name`
) VALUES (NULL , 'developer', 'romanb', 'Roman');
[2009-03-29 20:17:04] r dot borschel at gmx dot net
Description:
Associative array indices are getting garbled when usind pdo_mysql when
mysql pdo_mysql were compiled against libmysql. Compiling against
mysqlnd fixes the issue.
Reproduce code:
---
#
# SQL
#
CREATE TABLE IF NOT EXISTS `cms_users` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`status` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
`username` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
`name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
INSERT INTO `doctrinetests`.`cms_users` (
`id` ,
`status` ,
`username` ,
`name`
) VALUES (NULL , 'developer', 'romanb', 'Roman');
#
# PHP
#
$pdo = new PDO(mysql:host=localhost;dbname=testdb, xxx, xxx);
$stmt = $pdo-prepare(SELECT c0.id AS c0__id, c0.status AS c0__status,
c0.username AS c0__username, c0.name AS c0__name FROM cms_users c0);
$stmt-execute();
while ($data = $stmt-fetch(PDO::FETCH_ASSOC)) {
var_dump($data);
}
Expected result:
array(6) {
[c0__id]= string(2) 16
[c0__status]= string(9) developer
[c0__username]= string(6) romanb
[c0__name]= string(5) Roman
}
Actual result:
--
array(6) {
[c0__id]= string(2) 16
[status]= string(9) developer
[c0]= string(6) romanb
[cms_users]= string(5) Roman
}
--
Edit this bug report at http://bugs.php.net/?id=47832edit=1
#47815 [Asn]: Compile time computation of hash value decrease hash lookup time.
ID: 47815
Updated by: dmi...@php.net
Reported By: basant dot kukreja at gmail dot com
Status: Assigned
Bug Type: Performance problem
Operating System: Solaris 10
PHP Version: 5.2.9
Assigned To: dmitry
New Comment:
I like the idea, but I don't like some implementation details (addition
field in zend_opcode, tricky zend_std_read_property_hash() invocation).
However, I know that it's probably not possible to do it better.
I would like to make some benchmark tests, but the patch is broken.
Could you please put the patch somewhere or send it by email.
Previous Comments:
[2009-03-27 23:02:12] basant dot kukreja at gmail dot com
Some signifiant percentage of the time is spent in calculating the hash
value
of string contants.
If we compute the hash value of string constants during compilation
then
lookup time can be improved a lot.
With the above submitted patch results are better :
Excl. Incl. Name
User CPU User CPU
sec. sec.
414.450 726.638 zend_fetch_dimension_address
74.922238.016 zend_get_property_info_hval
Note the 150 second (~20 % time) less time spent in
zend_fetch_dimension_address and 190 second (45% time) reduction in
zend_get_property_info.
It showed 1% performance overall.
[2009-03-27 22:59:55] basant dot kukreja at gmail dot com
diff -r 00438f7eebe4 php-5.2.9RC3/Zend/zend_compile.h
--- a/php-5.2.9RC3/Zend/zend_compile.h Tue Mar 17 11:27:02 2009 -0700
+++ b/php-5.2.9RC3/Zend/zend_compile.h Fri Mar 27 10:18:13 2009 -0700
@@ -83,6 +83,7 @@
znode op1;
znode op2;
ulong extended_value;
+ ulong hval;
uint lineno;
zend_uchar opcode;
};
diff -r 00438f7eebe4 php-5.2.9RC3/Zend/zend_execute.c
--- a/php-5.2.9RC3/Zend/zend_execute.c Tue Mar 17 11:27:02 2009 -0700
+++ b/php-5.2.9RC3/Zend/zend_execute.c Fri Mar 27 10:18:13 2009 -0700
@@ -930,11 +930,12 @@
return NULL;
}
-static inline zval **zend_fetch_dimension_address_inner(HashTable *ht,
zval *dim, int type TSRMLS_DC)
+static inline zval **zend_fetch_dimension_address_inner(HashTable *ht,
zval *dim, int type, zend_ulong hval, int usehval TSRMLS_DC)
{
zval **retval;
char *offset_key;
int offset_key_length;
+ int ret;
switch (dim-type) {
case IS_NULL:
@@ -948,7 +949,13 @@
offset_key_length = dim-value.str.len;
fetch_string_dim:
- if (zend_symtable_find(ht, offset_key,
offset_key_length+1, (void
**) retval) == FAILURE) {
+ if (usehval) {
+ ret = zend_symtable_quick_find(ht, offset_key,
offset_key_length+1, hval, (void **) retval);
+ }
+ else {
+ ret = zend_symtable_find(ht, offset_key,
offset_key_length+1,
(void **) retval);
+ }
+ if (ret == FAILURE) {
switch (type) {
case BP_VAR_R:
zend_error(E_NOTICE, Undefined
index: %s, offset_key);
@@ -1023,7 +1030,7 @@
return retval;
}
-static void zend_fetch_dimension_address(temp_variable *result, zval
**container_ptr, zval *dim, int dim_is_tmp_var, int type TSRMLS_DC)
+static void zend_fetch_dimension_address(temp_variable *result, zval
**container_ptr, zval *dim, int dim_is_tmp_var, int type, zend_ulong
hval, int usehval TSRMLS_DC)
{
zval *container;
@@ -1078,7 +1085,7 @@
new_zval-refcount--;
}
} else {
- retval =
zend_fetch_dimension_address_inner(Z_ARRVAL_P(container),
dim, type TSRMLS_CC);
+ retval =
zend_fetch_dimension_address_inner(Z_ARRVAL_P(container),
dim, type, hval, usehval TSRMLS_CC);
}
if (result) {
result-var.ptr_ptr = retval;
diff -r 00438f7eebe4 php-5.2.9RC3/Zend/zend_hash.h
--- a/php-5.2.9RC3/Zend/zend_hash.h Tue Mar 17 11:27:02 2009 -0700
+++ b/php-5.2.9RC3/Zend/zend_hash.h Fri Mar 27 10:18:13 2009 -0700
@@ -354,6 +354,12 @@
return zend_hash_find(ht, arKey, nKeyLength, pData);
}
+static inline int zend_symtable_quick_find(HashTable *ht, char *arKey,
uint nKeyLength, ulong h, void **pData)
+{
+ HANDLE_NUMERIC(arKey, nKeyLength, zend_hash_index_find(ht, idx,
pData));
+ return zend_hash_quick_find(ht, arKey, nKeyLength, h, pData);
+}
+
static inline int zend_symtable_exists(HashTable *ht, char *arKey,
uint nKeyLength)
{
diff -r 00438f7eebe4 php-5.2.9RC3/Zend/zend_object_handlers.c
#47819 [Fbk-Opn]: Getting pdo_mysql.so: undefined symbol: mysqlnd_debug_init at startup
ID: 47819 User updated by: shahar dot e at zend dot com Reported By: shahar dot e at zend dot com -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Linux i386 PHP Version: 5.3.0RC1 Assigned To: mysql New Comment: Yes, I'm building PHP from scratch with the above mentioned configure command. I think that in order to reproduce this you need to add --enable-debug to your ./configure, as so (I just tried this): $ ./configure --disable-all --enable-pdo --with-pdo-mysql=shared,mysqlnd --enable-debug $ make $ sapi/cli/php -d extension_dir=modules/ -d extension=pdo_mysql.so -m PHP Warning: PHP Startup: Unable to load dynamic library 'modules/pdo_mysql.so' - modules/pdo_mysql.so: undefined symbol: mysqlnd_debug_init in Unknown on line 0 I assume that ext/mysqlnd/mysqlnd_debug.c needs to be added as a build dependency of pdo_mysql if --enable-debug is set, but I am not experienced enough with autoconf et al to figure this out exactly. Thanks, Shahar. Previous Comments: [2009-03-30 11:14:13] johan...@php.net Are you loading the module into a PHP which has mysqlnd enabled? Usually mysqlnd is automatically activated once another extension using mysqlnd is being activated. I tried the following which worked: $ ./configure --disable-all --enable-pdo --with-pdo-mysql=shared,mysqlnd $ make $ sapi/cli/php -d extension_dir=modules/ -d extension=pdo_mysql.so -m [2009-03-28 10:19:36] shahar dot e at zend dot com Description: I'm putting this under PDO even though this is probably a mysqlnd/build issue. I've compiled PHP5.3.0-RC1 with --enable-debug and --enable-pdo-mysql=mysqlnd,shared. When I try to load the PDO MySQL extension I get this: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/debug-non-zts-20090115/pdo_mysql.so' - /usr/local/lib/php/extensions/debug-non-zts-20090115/pdo_mysql.so: undefined symbol: mysqlnd_debug_init in Unknown on line 0 Some info: PHP Version = 5.3.0RC1 System = Linux wintergreen 2.6.28-gentoo-r2 #1 PREEMPT Sun Mar 8 17:10:56 IST 2009 i686 Build Date = Mar 27 2009 14:37:12 Configure Command = './configure' '--prefix=/usr/local' '--with-apxs2' '--enable-debug' '--with-openssl' '--with-pcre-regex' '--with-zlib' '--enable-bcmath=shared' '--with-bz2=shared' '--enable-calendar=shared' '--with-curl=shared' '--with-enchant=shared' '--enable-exif=shared' '--enable-ftp=shared' '--with-gd=shared' '--with-t 1lib' '--enable-gd-native-ttf' '--with-gettext=shared' '--enable-intl=shared' '--enable-mbstring=shared' '--with-mcrypt=shared' '--with-mysql=shared,mysqlnd' '--with- mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=shared,mysqlnd' '--enable-pcntl=shared' '--with-pdo-mysql=shared,mysqlnd' '--with-pdo-sqlite' '--with-readline' '--enable-soap=shared' '--enable-sockets=shared' '--enable-sqlite-utf8' '--with-tidy=shared' '--enable-zip=shared' '--with-pear' -- Edit this bug report at http://bugs.php.net/?id=47819edit=1
#47838 [NEW]: For some strict notices __autoload isn't used in the error handler
From: taco at procurios dot nl
Operating system: Ubuntu
PHP version: 5.2.9
PHP Bug Type: Unknown/Other Function
Bug description: For some strict notices __autoload isn't used in the error
handler
Description:
We dynamicly load a logging class in our error handler function using
autoload. For some STRICT notices (Declaration of Baz::bar() should be
compatible with that of Foo::bar()) the __autoload() function isn't called
to load that logging class.
If you replace the line require('php_bug1_2.php'); with mktime();,
which also casts an E_STRICT notice, you'll see the expected result instead
of the missing Qux class error.
Reproduce code:
---
http://thh.takkie.nl/php_bug1.php
Expected result:
My Error: Declaration of Baz::bar() should be compatible with that of
Foo::bar()
Stuff is done
Actual result:
--
My Error: Declaration of Baz::bar() should be compatible with that of
Foo::bar()
Fatal error: Class 'Qux' not found in
/data/www/thh.takkie.nl/public_html/php_bug1_2.php on line 15
--
Edit bug report at http://bugs.php.net/?id=47838edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47838r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47838r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47838r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47838r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47838r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47838r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47838r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47838r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47838r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47838r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47838r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47838r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47838r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47838r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47838r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47838r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47838r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47838r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47838r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47838r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47838r=mysqlcfg
#47819 [Opn-Asn]: Getting pdo_mysql.so: undefined symbol: mysqlnd_debug_init at startup
ID: 47819 Updated by: johan...@php.net Reported By: shahar dot e at zend dot com -Status: Open +Status: Assigned Bug Type: PDO related Operating System: Linux i386 PHP Version: 5.3.0RC1 Assigned To: mysql New Comment: Ah, the debug piece is important, investigating ... Previous Comments: [2009-03-30 11:59:05] shahar dot e at zend dot com Yes, I'm building PHP from scratch with the above mentioned configure command. I think that in order to reproduce this you need to add --enable-debug to your ./configure, as so (I just tried this): $ ./configure --disable-all --enable-pdo --with-pdo-mysql=shared,mysqlnd --enable-debug $ make $ sapi/cli/php -d extension_dir=modules/ -d extension=pdo_mysql.so -m PHP Warning: PHP Startup: Unable to load dynamic library 'modules/pdo_mysql.so' - modules/pdo_mysql.so: undefined symbol: mysqlnd_debug_init in Unknown on line 0 I assume that ext/mysqlnd/mysqlnd_debug.c needs to be added as a build dependency of pdo_mysql if --enable-debug is set, but I am not experienced enough with autoconf et al to figure this out exactly. Thanks, Shahar. [2009-03-30 11:14:13] johan...@php.net Are you loading the module into a PHP which has mysqlnd enabled? Usually mysqlnd is automatically activated once another extension using mysqlnd is being activated. I tried the following which worked: $ ./configure --disable-all --enable-pdo --with-pdo-mysql=shared,mysqlnd $ make $ sapi/cli/php -d extension_dir=modules/ -d extension=pdo_mysql.so -m [2009-03-28 10:19:36] shahar dot e at zend dot com Description: I'm putting this under PDO even though this is probably a mysqlnd/build issue. I've compiled PHP5.3.0-RC1 with --enable-debug and --enable-pdo-mysql=mysqlnd,shared. When I try to load the PDO MySQL extension I get this: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/debug-non-zts-20090115/pdo_mysql.so' - /usr/local/lib/php/extensions/debug-non-zts-20090115/pdo_mysql.so: undefined symbol: mysqlnd_debug_init in Unknown on line 0 Some info: PHP Version = 5.3.0RC1 System = Linux wintergreen 2.6.28-gentoo-r2 #1 PREEMPT Sun Mar 8 17:10:56 IST 2009 i686 Build Date = Mar 27 2009 14:37:12 Configure Command = './configure' '--prefix=/usr/local' '--with-apxs2' '--enable-debug' '--with-openssl' '--with-pcre-regex' '--with-zlib' '--enable-bcmath=shared' '--with-bz2=shared' '--enable-calendar=shared' '--with-curl=shared' '--with-enchant=shared' '--enable-exif=shared' '--enable-ftp=shared' '--with-gd=shared' '--with-t 1lib' '--enable-gd-native-ttf' '--with-gettext=shared' '--enable-intl=shared' '--enable-mbstring=shared' '--with-mcrypt=shared' '--with-mysql=shared,mysqlnd' '--with- mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=shared,mysqlnd' '--enable-pcntl=shared' '--with-pdo-mysql=shared,mysqlnd' '--with-pdo-sqlite' '--with-readline' '--enable-soap=shared' '--enable-sockets=shared' '--enable-sqlite-utf8' '--with-tidy=shared' '--enable-zip=shared' '--with-pear' -- Edit this bug report at http://bugs.php.net/?id=47819edit=1
#45468 [Com]: socket file problem when mysqlnd is enabled
ID: 45468 Comment by: gerry dot spm+phpbug at gmail dot com Reported By: michael dot kofler at gmx dot com Status: No Feedback Bug Type: MySQLi related Operating System: * PHP Version: 5.3.0alpha1 Assigned To: mysql New Comment: I am a complete noob to compiling PHP (and linux in general) so this is probably something that I'm doing wrong. I'll probably switch back to using the old command until this is fixed, but I just though I'd let you know that I am having the same issue. Previously I was running PHP 5.2.9 with the following config: ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=/usr/bin/mysql_config \ --with-mysqli=/usr/bin/mysql_config \ --with-mcrypt \ --enable-mbstring \ --with-zlib \ --with-bz2 \ --with-gd \ --with-zlib-dir \ --with-jpeg-dir \ --with-curl All worked fine in this config, but today I downloaded RC1 of PHP 5.3 and slightly modified my config to use mysqlnd: sudo ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=mysqlnd \ --with-mysqli=mysqlnd \ --with-mcrypt \ --enable-mbstring \ --with-zlib \ --with-bz2 \ --with-gd \ --with-zlib-dir \ --with-jpeg-dir \ --with-curl I am now also receiving the error: Connect Error (2002) No such file or directory Previous Comments: [2009-02-11 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-02-03 11:59:28] and...@php.net Hi, it was a problem, the Unix path, in the extensions, not mysqlnd. Yes, mysqlnd uses /tmp/mysql.sock, but actually there are no configure options for mysqlnd. --with-mysql-sock is actually an option of ext/mysql . It wasn't used in the past, as far as I recall, but current 5_3 and HEAD do use it to set default value for the socket path, which can be overwritten by the user. Both for ext/mysql and mysqli. This if from ext/mysql/php_mysql.c : #ifdef MYSQL_UNIX_ADDR STD_PHP_INI_ENTRY(mysql.default_socket, MYSQL_UNIX_ADDR,PHP_INI_ALL,OnUpdateStringUnempty, default_socket, zend_mysql_globals, mysql_globals) #else STD_PHP_INI_ENTRY(mysql.default_socket, NULL, PHP_INI_ALL,OnUpdateStringUnempty, default_socket, zend_mysql_globals, mysql_globals) #endif This is from ext/mysqli/mysql.c : #ifdef PHP_MYSQL_UNIX_SOCK_ADDR STD_PHP_INI_ENTRY(mysqli.default_socket, MYSQL_UNIX_ADDR,PHP_INI_ALL,OnUpdateStringUnempty, default_socket, zend_mysqli_globals,mysqli_globals) #else STD_PHP_INI_ENTRY(mysqli.default_socket, NULL, PHP_INI_ALL,OnUpdateStringUnempty, default_socket, zend_mysqli_globals,mysqli_globals) #endif MYSQL_UNIX_ADDR is a macro, for PHP_MYSQL_UNIX_ADDR, which is defined by the configure script if --with-mysql-sock is used. In this regard, PDO doesn't use --with-mysql-sock. PDO_MYSQL used mysql_config to find the socket, but for mysqln defaults to /tmp/mysql.sock , which seems like bug, because of inconsistency. This is something for Johannes Best, Andrey [2009-02-03 11:43:38] johan...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ --with-mysql-sock should work now properly [2008-08-19 20:32:28] bob dot kellum at gmail dot com Another possibility is to use the method described on this page: http://dev.mysql.com/doc/refman/5.1/en/old-client.html to craft an account that uses the older authentication scheme. This page states that many PHP applications may need to use this workaround. I found it (and this page) while troubleshooting a different old client issue. [2008-08-07 08:01:44] michael dot kofler at gmx dot com re-tested on Linux with alpha1, compiled with this configuration: configure --with-mysqli=mysqlnd \ --with-mysql=mysqlnd \ --with-mysql-sock=/var/run/mysqld/mysqld.sock \ --enable-pdo \ --with-pdo-mysql=mysqlnd \ --with-apxs2=/usr/bin/apxs2 \ --with-zlib \ --with-gd \ --with-config-file-scan-dir=/etc/php5/apache2 \ --with-jpeg-dir=/usr/lib \ --enable-exif \ --libdir=/usr/lib \ --enable-mbstring also tried --with-mysql-sock=/var/run/mysqld \ result: mysql, mysqli and PDO/mysql, all using mysqlnd, still look for the socket file /tmp/mysql.sock and ignore --with-mysql-sock
#47819 [Asn-Fbk]: Getting pdo_mysql.so: undefined symbol: mysqlnd_debug_init at startup
ID: 47819 Updated by: johan...@php.net Reported By: shahar dot e at zend dot com -Status: Assigned +Status: Feedback Bug Type: PDO related Operating System: Linux i386 PHP Version: 5.3.0RC1 Assigned To: mysql New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I still didn't reproduce it but applied a patch with some guessing. Please try the snapshot and see whether it helps. Previous Comments: [2009-03-30 13:15:58] johan...@php.net Ah, the debug piece is important, investigating ... [2009-03-30 11:59:05] shahar dot e at zend dot com Yes, I'm building PHP from scratch with the above mentioned configure command. I think that in order to reproduce this you need to add --enable-debug to your ./configure, as so (I just tried this): $ ./configure --disable-all --enable-pdo --with-pdo-mysql=shared,mysqlnd --enable-debug $ make $ sapi/cli/php -d extension_dir=modules/ -d extension=pdo_mysql.so -m PHP Warning: PHP Startup: Unable to load dynamic library 'modules/pdo_mysql.so' - modules/pdo_mysql.so: undefined symbol: mysqlnd_debug_init in Unknown on line 0 I assume that ext/mysqlnd/mysqlnd_debug.c needs to be added as a build dependency of pdo_mysql if --enable-debug is set, but I am not experienced enough with autoconf et al to figure this out exactly. Thanks, Shahar. [2009-03-30 11:14:13] johan...@php.net Are you loading the module into a PHP which has mysqlnd enabled? Usually mysqlnd is automatically activated once another extension using mysqlnd is being activated. I tried the following which worked: $ ./configure --disable-all --enable-pdo --with-pdo-mysql=shared,mysqlnd $ make $ sapi/cli/php -d extension_dir=modules/ -d extension=pdo_mysql.so -m [2009-03-28 10:19:36] shahar dot e at zend dot com Description: I'm putting this under PDO even though this is probably a mysqlnd/build issue. I've compiled PHP5.3.0-RC1 with --enable-debug and --enable-pdo-mysql=mysqlnd,shared. When I try to load the PDO MySQL extension I get this: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/debug-non-zts-20090115/pdo_mysql.so' - /usr/local/lib/php/extensions/debug-non-zts-20090115/pdo_mysql.so: undefined symbol: mysqlnd_debug_init in Unknown on line 0 Some info: PHP Version = 5.3.0RC1 System = Linux wintergreen 2.6.28-gentoo-r2 #1 PREEMPT Sun Mar 8 17:10:56 IST 2009 i686 Build Date = Mar 27 2009 14:37:12 Configure Command = './configure' '--prefix=/usr/local' '--with-apxs2' '--enable-debug' '--with-openssl' '--with-pcre-regex' '--with-zlib' '--enable-bcmath=shared' '--with-bz2=shared' '--enable-calendar=shared' '--with-curl=shared' '--with-enchant=shared' '--enable-exif=shared' '--enable-ftp=shared' '--with-gd=shared' '--with-t 1lib' '--enable-gd-native-ttf' '--with-gettext=shared' '--enable-intl=shared' '--enable-mbstring=shared' '--with-mcrypt=shared' '--with-mysql=shared,mysqlnd' '--with- mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=shared,mysqlnd' '--enable-pcntl=shared' '--with-pdo-mysql=shared,mysqlnd' '--with-pdo-sqlite' '--with-readline' '--enable-soap=shared' '--enable-sockets=shared' '--enable-sqlite-utf8' '--with-tidy=shared' '--enable-zip=shared' '--with-pear' -- Edit this bug report at http://bugs.php.net/?id=47819edit=1
#47832 [Opn-Fbk]: Garbled associative array indices
ID: 47832
Updated by: johan...@php.net
Reported By: r dot borschel at gmx dot net
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: OS X 10.5.6
PHP Version: 5.3CVS-2009-03-29 (snap)
Assigned To: mysql
New Comment:
hm, interesting mixup, can you try doing
ldd sapi/cli/php | grep mysql
to see which libmysql is being loaded?
Previous Comments:
[2009-03-30 12:35:27] r dot borschel at gmx dot net
$ sapi/cli/php --ri pdo_mysql
pdo_mysql
PDO Driver for MySQL = enabled
Client API version = 5.0.38
Thats a bit strange, isnt it? My configure looks like this:
'./configure' \
...
'--with-mysql=/usr/local/mysql-5.1.32-osx10.5-x86' \
'--with-pdo-mysql=/usr/local/mysql-5.1.32-osx10.5-x86' \
...
That version mismatch may be the problem? Am I doing something
obviously wrong?
Thanks for your help.
[2009-03-30 11:44:41] johan...@php.net
Which MySQL server and client library versions are you using? - I
tested using 5.1.31 worked for me:
$ sapi/cli/php --ri pdo_mysql
pdo_mysql
PDO Driver for MySQL = enabled
Client API version = 5.1.31
$ sapi/cli/php bug47832.php
array(4) {
[c0__id]=
string(1) 1
[c0__status]=
string(9) developer
[c0__username]=
string(6) romanb
[c0__name]=
string(5) Roman
}
[2009-03-29 20:19:46] r dot borschel at gmx dot net
The INSERT statement should of course read:
INSERT INTO `testdb`.`cms_users` (
`id` ,
`status` ,
`username` ,
`name`
) VALUES (NULL , 'developer', 'romanb', 'Roman');
[2009-03-29 20:17:04] r dot borschel at gmx dot net
Description:
Associative array indices are getting garbled when usind pdo_mysql when
mysql pdo_mysql were compiled against libmysql. Compiling against
mysqlnd fixes the issue.
Reproduce code:
---
#
# SQL
#
CREATE TABLE IF NOT EXISTS `cms_users` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`status` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
`username` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
`name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
INSERT INTO `doctrinetests`.`cms_users` (
`id` ,
`status` ,
`username` ,
`name`
) VALUES (NULL , 'developer', 'romanb', 'Roman');
#
# PHP
#
$pdo = new PDO(mysql:host=localhost;dbname=testdb, xxx, xxx);
$stmt = $pdo-prepare(SELECT c0.id AS c0__id, c0.status AS c0__status,
c0.username AS c0__username, c0.name AS c0__name FROM cms_users c0);
$stmt-execute();
while ($data = $stmt-fetch(PDO::FETCH_ASSOC)) {
var_dump($data);
}
Expected result:
array(6) {
[c0__id]= string(2) 16
[c0__status]= string(9) developer
[c0__username]= string(6) romanb
[c0__name]= string(5) Roman
}
Actual result:
--
array(6) {
[c0__id]= string(2) 16
[status]= string(9) developer
[c0]= string(6) romanb
[cms_users]= string(5) Roman
}
--
Edit this bug report at http://bugs.php.net/?id=47832edit=1
#47838 [Com]: For some strict notices __autoload isn't used in the error handler
ID: 47838
Comment by: sander dot vink at procurios dot nl
Reported By: taco at procurios dot nl
Status: Open
Bug Type: Unknown/Other Function
Operating System: Ubuntu
PHP Version: 5.2.9
New Comment:
The same error occurs on the latest snapshot of PHP5.3 (Built on: Mar
30, 2009 12:30 UTC):
Actual result:
--
My Error: Declaration of Baz::bar() should be compatible with that of
Foo::bar()
Fatal error: Class 'Qux' not found in
/Users/svink/Desktop/bugtest/php_bug1_2.php on line 15
Previous Comments:
[2009-03-30 12:55:40] taco at procurios dot nl
Description:
We dynamicly load a logging class in our error handler function using
autoload. For some STRICT notices (Declaration of Baz::bar() should be
compatible with that of Foo::bar()) the __autoload() function isn't
called to load that logging class.
If you replace the line require('php_bug1_2.php'); with mktime();,
which also casts an E_STRICT notice, you'll see the expected result
instead of the missing Qux class error.
Reproduce code:
---
http://thh.takkie.nl/php_bug1.php
Expected result:
My Error: Declaration of Baz::bar() should be compatible with that of
Foo::bar()
Stuff is done
Actual result:
--
My Error: Declaration of Baz::bar() should be compatible with that of
Foo::bar()
Fatal error: Class 'Qux' not found in
/data/www/thh.takkie.nl/public_html/php_bug1_2.php on line 15
--
Edit this bug report at http://bugs.php.net/?id=47838edit=1
#47832 [Fbk]: Garbled associative array indices
ID: 47832
Updated by: johan...@php.net
Reported By: r dot borschel at gmx dot net
Status: Feedback
Bug Type: PDO related
Operating System: OS X 10.5.6
PHP Version: 5.3CVS-2009-03-29 (snap)
Assigned To: mysql
New Comment:
don't have a mac at hand, if ldd doesn't work try otool -L (which is
part of the developer tools)
Previous Comments:
[2009-03-30 14:27:23] johan...@php.net
hm, interesting mixup, can you try doing
ldd sapi/cli/php | grep mysql
to see which libmysql is being loaded?
[2009-03-30 12:35:27] r dot borschel at gmx dot net
$ sapi/cli/php --ri pdo_mysql
pdo_mysql
PDO Driver for MySQL = enabled
Client API version = 5.0.38
Thats a bit strange, isnt it? My configure looks like this:
'./configure' \
...
'--with-mysql=/usr/local/mysql-5.1.32-osx10.5-x86' \
'--with-pdo-mysql=/usr/local/mysql-5.1.32-osx10.5-x86' \
...
That version mismatch may be the problem? Am I doing something
obviously wrong?
Thanks for your help.
[2009-03-30 11:44:41] johan...@php.net
Which MySQL server and client library versions are you using? - I
tested using 5.1.31 worked for me:
$ sapi/cli/php --ri pdo_mysql
pdo_mysql
PDO Driver for MySQL = enabled
Client API version = 5.1.31
$ sapi/cli/php bug47832.php
array(4) {
[c0__id]=
string(1) 1
[c0__status]=
string(9) developer
[c0__username]=
string(6) romanb
[c0__name]=
string(5) Roman
}
[2009-03-29 20:19:46] r dot borschel at gmx dot net
The INSERT statement should of course read:
INSERT INTO `testdb`.`cms_users` (
`id` ,
`status` ,
`username` ,
`name`
) VALUES (NULL , 'developer', 'romanb', 'Roman');
[2009-03-29 20:17:04] r dot borschel at gmx dot net
Description:
Associative array indices are getting garbled when usind pdo_mysql when
mysql pdo_mysql were compiled against libmysql. Compiling against
mysqlnd fixes the issue.
Reproduce code:
---
#
# SQL
#
CREATE TABLE IF NOT EXISTS `cms_users` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`status` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
`username` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
`name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
INSERT INTO `doctrinetests`.`cms_users` (
`id` ,
`status` ,
`username` ,
`name`
) VALUES (NULL , 'developer', 'romanb', 'Roman');
#
# PHP
#
$pdo = new PDO(mysql:host=localhost;dbname=testdb, xxx, xxx);
$stmt = $pdo-prepare(SELECT c0.id AS c0__id, c0.status AS c0__status,
c0.username AS c0__username, c0.name AS c0__name FROM cms_users c0);
$stmt-execute();
while ($data = $stmt-fetch(PDO::FETCH_ASSOC)) {
var_dump($data);
}
Expected result:
array(6) {
[c0__id]= string(2) 16
[c0__status]= string(9) developer
[c0__username]= string(6) romanb
[c0__name]= string(5) Roman
}
Actual result:
--
array(6) {
[c0__id]= string(2) 16
[status]= string(9) developer
[c0]= string(6) romanb
[cms_users]= string(5) Roman
}
--
Edit this bug report at http://bugs.php.net/?id=47832edit=1
#47828 [Csd]: Seg Fault in openssl_x509_parse
ID: 47828 User updated by: reinke at securityspace dot com Reported By: reinke at securityspace dot com Status: Closed Bug Type: OpenSSL related Operating System: Linux (Debian Lenny) PHP Version: 5.2.9 Assigned To: scottmac New Comment: No, our official distributions channel is http://www.php.net/downloads and http://windows.php.net, nothing else. Pierre - that's wishful thinking and a pile of crock. Argue over the semantics of official however you wish. The reality, however, is that about 28% of all web sites with PHP are known to be using a Distro version of PHP. And of the remaining 72%, we can't even say they are using a version from your web site, only that we don't know if they are using your version, or one from a distro. Don't get me wrong - your (PHP's) fix time on this was absolutely amazing, and to repeat, we have no issue with helping out on a problem. But telling folks not to use a distro version of PHP is just not in line with reality. And for the record - every 5.2.x install we've touched on a Linux box was vulnerable. If you couldn't reproduce on Ubuntu or Debian using the concise 3 line script provided after several hours of our digging to make it easy on you, perhaps you need to have a broader range of hardware to check on. Every x86 based install WE checked on 5.2.x was vulnerable and reproduced the problem. INCLUDING your latest snapshot. Grumble - you ought to take this thread and mark it as a how to take a customer that was willing to help find a bug that crashes your application and really piss him off. Scott - thanks for the quick fix. Above and beyond. Thomas Previous Comments: [2009-03-30 09:59:49] paj...@php.net Firt, I do not care if it took 0.5 second or 3 hours. Secondly, the bug is less than a day old, we did run test and it did not crash on all platforms I can test (windows, ubuntu x64/x86 and debian). So not it was not obvious that there was a real bug in the current code. And finally, you can't know if a) there is already a patch or a fix and b) what's the status, simply because you did not bother to ask. There is no problem to take over any bug as long as you simply ask before. It will save us time and pains (as in this kind of discussions, which happen only with you). Thanks for your understanding and your work. [2009-03-30 09:24:43] scott...@php.net Pierre using the test given by the reporter I could reproduce this, took less than a minute to find the issue. Assigning yourself a bug that you'll look at next week isn't all that useful, especially if someone with more time comes along in that next week. Perhaps we need to add multiple assignment to bugs? FYI OpenSSL verions OpenSSL 0.9.7l 28 Sep 2006 (OS X default) OpenSSL 0.9.8j 07 Jan 2009 [2009-03-30 06:00:06] paj...@php.net With all due respect - we are using PHP's official release. On Debian. As provided by the distro. On Ubuntu. As provided by Ubuntu. On Fedora. As provided by... well, you get it. Like it or not, these vendors are your distribution channel No, our official distributions channel is http://www.php.net/downloads and http://windows.php.net, nothing else. Distributions, in their majority, do a great job at distributing php but they are not our official releases channel, especially not when they use unofficial patches like suhosin or other random changes. The reason we ask to try PHP's version is to be sure about the src of the problem, we have no control over what the distros do or don't. [2009-03-30 05:52:22] paj...@php.net Scott, that's nice but add a test please with the data you use to reproduce the segfault. [2009-03-29 23:45:51] scott...@php.net I fixed it about 10 minutes ago, the snapshot is from a few hours ago. 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/47828 -- Edit this bug report at http://bugs.php.net/?id=47828edit=1
#47819 [Com]: Getting pdo_mysql.so: undefined symbol: mysqlnd_debug_init at startup
ID: 47819 Comment by: shahar dot e at zend dot com Reported By: shahar dot e at zend dot com Status: Feedback Bug Type: PDO related Operating System: Linux i386 PHP Version: 5.3.0RC1 Assigned To: mysql New Comment: This still happens with the latest snapshot you linked to. Here are the relevant parts from sapi/cli/php -i: PHP Version = 5.3.0RC2-dev System = Linux wintergreen 2.6.28-gentoo-r2 #1 PREEMPT Sun Mar 8 17:10:56 IST 2009 i686 Build Date = Mar 30 2009 17:42:20 Configure Command = './configure' '--disable-all' '--enable-pdo' '--with-pdo-mysql=shared,mysqlnd' '--enable-debug' Server API = Command Line Interface Debug Build = yes Thread Safety = disabled mysqlnd mysqlnd = enabled Version = mysqlnd 5.0.5-dev - 081106 - $Revision: 1.3.2.22 $ Command buffer size = 2048 Read buffer size = 32768 Collecting statistics = Yes Collecting memory statistics = No PDO PDO support = enabled Previous Comments: [2009-03-30 14:06:49] johan...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I still didn't reproduce it but applied a patch with some guessing. Please try the snapshot and see whether it helps. [2009-03-30 13:15:58] johan...@php.net Ah, the debug piece is important, investigating ... [2009-03-30 11:59:05] shahar dot e at zend dot com Yes, I'm building PHP from scratch with the above mentioned configure command. I think that in order to reproduce this you need to add --enable-debug to your ./configure, as so (I just tried this): $ ./configure --disable-all --enable-pdo --with-pdo-mysql=shared,mysqlnd --enable-debug $ make $ sapi/cli/php -d extension_dir=modules/ -d extension=pdo_mysql.so -m PHP Warning: PHP Startup: Unable to load dynamic library 'modules/pdo_mysql.so' - modules/pdo_mysql.so: undefined symbol: mysqlnd_debug_init in Unknown on line 0 I assume that ext/mysqlnd/mysqlnd_debug.c needs to be added as a build dependency of pdo_mysql if --enable-debug is set, but I am not experienced enough with autoconf et al to figure this out exactly. Thanks, Shahar. [2009-03-30 11:14:13] johan...@php.net Are you loading the module into a PHP which has mysqlnd enabled? Usually mysqlnd is automatically activated once another extension using mysqlnd is being activated. I tried the following which worked: $ ./configure --disable-all --enable-pdo --with-pdo-mysql=shared,mysqlnd $ make $ sapi/cli/php -d extension_dir=modules/ -d extension=pdo_mysql.so -m [2009-03-28 10:19:36] shahar dot e at zend dot com Description: I'm putting this under PDO even though this is probably a mysqlnd/build issue. I've compiled PHP5.3.0-RC1 with --enable-debug and --enable-pdo-mysql=mysqlnd,shared. When I try to load the PDO MySQL extension I get this: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/debug-non-zts-20090115/pdo_mysql.so' - /usr/local/lib/php/extensions/debug-non-zts-20090115/pdo_mysql.so: undefined symbol: mysqlnd_debug_init in Unknown on line 0 Some info: PHP Version = 5.3.0RC1 System = Linux wintergreen 2.6.28-gentoo-r2 #1 PREEMPT Sun Mar 8 17:10:56 IST 2009 i686 Build Date = Mar 27 2009 14:37:12 Configure Command = './configure' '--prefix=/usr/local' '--with-apxs2' '--enable-debug' '--with-openssl' '--with-pcre-regex' '--with-zlib' '--enable-bcmath=shared' '--with-bz2=shared' '--enable-calendar=shared' '--with-curl=shared' '--with-enchant=shared' '--enable-exif=shared' '--enable-ftp=shared' '--with-gd=shared' '--with-t 1lib' '--enable-gd-native-ttf' '--with-gettext=shared' '--enable-intl=shared' '--enable-mbstring=shared' '--with-mcrypt=shared' '--with-mysql=shared,mysqlnd' '--with- mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=shared,mysqlnd' '--enable-pcntl=shared' '--with-pdo-mysql=shared,mysqlnd' '--with-pdo-sqlite' '--with-readline' '--enable-soap=shared' '--enable-sockets=shared' '--enable-sqlite-utf8' '--with-tidy=shared' '--enable-zip=shared' '--with-pear' -- Edit this bug report at http://bugs.php.net/?id=47819edit=1
#47828 [Csd]: Seg Fault in openssl_x509_parse
ID: 47828 Updated by: paj...@php.net Reported By: reinke at securityspace dot com Status: Closed Bug Type: OpenSSL related Operating System: Linux (Debian Lenny) PHP Version: 5.2.9 Assigned To: scottmac New Comment: Note that even people from Ubuntu security were not able to reproduce it (I asked them to take a look at the report). So excuse me but there were doubts about this bug, like it or not. And that's why I asked you to test with our src, you did, thanks. Also I did not ask you to do not use the distribution version of php but to use our sources to see if the bug can be reproduced. It is common practice to ask that, not only in php. Previous Comments: [2009-03-30 14:43:12] reinke at securityspace dot com No, our official distributions channel is http://www.php.net/downloads and http://windows.php.net, nothing else. Pierre - that's wishful thinking and a pile of crock. Argue over the semantics of official however you wish. The reality, however, is that about 28% of all web sites with PHP are known to be using a Distro version of PHP. And of the remaining 72%, we can't even say they are using a version from your web site, only that we don't know if they are using your version, or one from a distro. Don't get me wrong - your (PHP's) fix time on this was absolutely amazing, and to repeat, we have no issue with helping out on a problem. But telling folks not to use a distro version of PHP is just not in line with reality. And for the record - every 5.2.x install we've touched on a Linux box was vulnerable. If you couldn't reproduce on Ubuntu or Debian using the concise 3 line script provided after several hours of our digging to make it easy on you, perhaps you need to have a broader range of hardware to check on. Every x86 based install WE checked on 5.2.x was vulnerable and reproduced the problem. INCLUDING your latest snapshot. Grumble - you ought to take this thread and mark it as a how to take a customer that was willing to help find a bug that crashes your application and really piss him off. Scott - thanks for the quick fix. Above and beyond. Thomas [2009-03-30 09:59:49] paj...@php.net Firt, I do not care if it took 0.5 second or 3 hours. Secondly, the bug is less than a day old, we did run test and it did not crash on all platforms I can test (windows, ubuntu x64/x86 and debian). So not it was not obvious that there was a real bug in the current code. And finally, you can't know if a) there is already a patch or a fix and b) what's the status, simply because you did not bother to ask. There is no problem to take over any bug as long as you simply ask before. It will save us time and pains (as in this kind of discussions, which happen only with you). Thanks for your understanding and your work. [2009-03-30 09:24:43] scott...@php.net Pierre using the test given by the reporter I could reproduce this, took less than a minute to find the issue. Assigning yourself a bug that you'll look at next week isn't all that useful, especially if someone with more time comes along in that next week. Perhaps we need to add multiple assignment to bugs? FYI OpenSSL verions OpenSSL 0.9.7l 28 Sep 2006 (OS X default) OpenSSL 0.9.8j 07 Jan 2009 [2009-03-30 06:00:06] paj...@php.net With all due respect - we are using PHP's official release. On Debian. As provided by the distro. On Ubuntu. As provided by Ubuntu. On Fedora. As provided by... well, you get it. Like it or not, these vendors are your distribution channel No, our official distributions channel is http://www.php.net/downloads and http://windows.php.net, nothing else. Distributions, in their majority, do a great job at distributing php but they are not our official releases channel, especially not when they use unofficial patches like suhosin or other random changes. The reason we ask to try PHP's version is to be sure about the src of the problem, we have no control over what the distros do or don't. [2009-03-30 05:52:22] paj...@php.net Scott, that's nice but add a test please with the data you use to reproduce the segfault. 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/47828 -- Edit this bug report at http://bugs.php.net/?id=47828edit=1
#47832 [Fbk-Opn]: Garbled associative array indices
ID: 47832
User updated by: r dot borschel at gmx dot net
Reported By: r dot borschel at gmx dot net
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: OS X 10.5.6
PHP Version: 5.3CVS-2009-03-29 (snap)
Assigned To: mysql
New Comment:
That's interesting. Here is the output:
$ otool -L sapi/cli/php | grep mysql
/sw/lib/mysql/libmysqlclient.15.dylib (compatibility version 16.0.0,
current version 16.0.0)
So the libmysql getting loaded is from Fink (/sw is the root directory
of Fink). Clearly this is not what I wanted. Here is my complete
configure listing:
'./configure' \
'--prefix=/usr/local/php-5.3' \
'--with-apxs2=/usr/local/apache2.2.9/bin/apxs' \
'--enable-exif' \
'--with-gd' \
'--with-jpeg-dir=/sw' \
'--with-png-dir=/sw' \
'--enable-mbstring' \
'--with-mcrypt=/sw' \
'--with-mhash=/sw' \
'--with-iconv' \
'--with-mysql=/usr/local/mysql-5.1.32-osx10.5-x86' \
'--with-pdo-mysql=/usr/local/mysql-5.1.32-osx10.5-x86' \
'--with-pdo-pgsql=/usr/local/pgsql' \
'--with-pgsql=/usr/local/pgsql/' \
'--with-curl=/sw' \
'--with-zlib-dir=/sw' \
'--enable-soap' \
'--enable-sqlite-utf8' \
'--enable-zip' \
As you can see I'm using Fink libraries for some of the dependencies
but clearly not for mysql. It seems, however, that the Fink libmysql is
chosen anyway for whatever reason (/sw paths are prepended to the $PATH
so maybe that has something to do with it)
It's good to see that this issue is rather caused by a version mess
on my side even though the resulting behavior is a bit scary because it
does not indicate any errors, just garbled results.
Thanks for helping me resolve this issue. As far as I am concerned this
does not seem like a PHP-related issue and I guess unpredictable
behavior is supposed to be expected when using incompatible versions.
Feel free to close this issue if you think it does not deserve any
further attention.
Previous Comments:
[2009-03-30 14:35:49] johan...@php.net
don't have a mac at hand, if ldd doesn't work try otool -L (which is
part of the developer tools)
[2009-03-30 14:27:23] johan...@php.net
hm, interesting mixup, can you try doing
ldd sapi/cli/php | grep mysql
to see which libmysql is being loaded?
[2009-03-30 12:35:27] r dot borschel at gmx dot net
$ sapi/cli/php --ri pdo_mysql
pdo_mysql
PDO Driver for MySQL = enabled
Client API version = 5.0.38
Thats a bit strange, isnt it? My configure looks like this:
'./configure' \
...
'--with-mysql=/usr/local/mysql-5.1.32-osx10.5-x86' \
'--with-pdo-mysql=/usr/local/mysql-5.1.32-osx10.5-x86' \
...
That version mismatch may be the problem? Am I doing something
obviously wrong?
Thanks for your help.
[2009-03-30 11:44:41] johan...@php.net
Which MySQL server and client library versions are you using? - I
tested using 5.1.31 worked for me:
$ sapi/cli/php --ri pdo_mysql
pdo_mysql
PDO Driver for MySQL = enabled
Client API version = 5.1.31
$ sapi/cli/php bug47832.php
array(4) {
[c0__id]=
string(1) 1
[c0__status]=
string(9) developer
[c0__username]=
string(6) romanb
[c0__name]=
string(5) Roman
}
[2009-03-29 20:19:46] r dot borschel at gmx dot net
The INSERT statement should of course read:
INSERT INTO `testdb`.`cms_users` (
`id` ,
`status` ,
`username` ,
`name`
) VALUES (NULL , 'developer', 'romanb', 'Roman');
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/47832
--
Edit this bug report at http://bugs.php.net/?id=47832edit=1
#47840 [NEW]: __call ignored when extending PDO
From: oorza2k5 at gmail dot com
Operating system: Linux
PHP version: 5.2.9
PHP Bug Type: PDO related
Bug description: __call ignored when extending PDO
Description:
Exact same issue (that was supposedly resolved) as #44425, but now with a
MySQL 5.1 database.
__call() doesn't do anything when extending PDO.
This bug is clearly not fixed.
Reproduce code:
---
Reproduce code:
---
?php
class test extends PDO {
function __call($name, array $args) {
echo Called $name in .__CLASS__.'br';
}
function foo() {
echo Called foo in .__CLASS__.'br';
}
}
$a = new test('mysql:dbname=test;host=localhost','user','pw');
$a-foo();
$a-bar();
?
Expected result:
Called foo in test
Called bar in test
Actual result:
--
Called foo in testbr
Fatal error: Call to undefined method test::bar() in test4.php on line 12
--
Edit bug report at http://bugs.php.net/?id=47840edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47840r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47840r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47840r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47840r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47840r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47840r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47840r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47840r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47840r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47840r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47840r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47840r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47840r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47840r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47840r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47840r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47840r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47840r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47840r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47840r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47840r=mysqlcfg
#47840 [Opn-Fbk]: __call ignored when extending PDO
ID: 47840
Updated by: fel...@php.net
Reported By: oorza2k5 at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.2.9
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2009-03-30 16:45:08] oorza2k5 at gmail dot com
Description:
Exact same issue (that was supposedly resolved) as #44425, but now with
a MySQL 5.1 database.
__call() doesn't do anything when extending PDO.
This bug is clearly not fixed.
Reproduce code:
---
Reproduce code:
---
?php
class test extends PDO {
function __call($name, array $args) {
echo Called $name in .__CLASS__.'br';
}
function foo() {
echo Called foo in .__CLASS__.'br';
}
}
$a = new test('mysql:dbname=test;host=localhost','user','pw');
$a-foo();
$a-bar();
?
Expected result:
Called foo in test
Called bar in test
Actual result:
--
Called foo in testbr
Fatal error: Call to undefined method test::bar() in test4.php on line
12
--
Edit this bug report at http://bugs.php.net/?id=47840edit=1
#47840 [Com]: __call ignored when extending PDO
ID: 47840
Comment by: oorza2k5 at gmail dot com
Reported By: oorza2k5 at gmail dot com
Status: Feedback
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.2.9
New Comment:
It works as expected in the latest CVS under Windows... I don't have a
non-production Linux install to test with, so if someone else could
verify it's fixed in CVS (under Linux), that'd be great.
Previous Comments:
[2009-03-30 16:48:36] fel...@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-03-30 16:45:08] oorza2k5 at gmail dot com
Description:
Exact same issue (that was supposedly resolved) as #44425, but now with
a MySQL 5.1 database.
__call() doesn't do anything when extending PDO.
This bug is clearly not fixed.
Reproduce code:
---
Reproduce code:
---
?php
class test extends PDO {
function __call($name, array $args) {
echo Called $name in .__CLASS__.'br';
}
function foo() {
echo Called foo in .__CLASS__.'br';
}
}
$a = new test('mysql:dbname=test;host=localhost','user','pw');
$a-foo();
$a-bar();
?
Expected result:
Called foo in test
Called bar in test
Actual result:
--
Called foo in testbr
Fatal error: Call to undefined method test::bar() in test4.php on line
12
--
Edit this bug report at http://bugs.php.net/?id=47840edit=1
#47812 [Com]: undefined symbol: gdJpegGetVersionInt
ID: 47812 Comment by: oeriksson at mandriva dot com Reported By: oeriksson at mandriva dot com Status: Assigned Bug Type: GD related Operating System: Mandriva Linux PHP Version: 5.3.0RC1 Assigned To: pajoye New Comment: Thanks Pierre, I'm looking forward to a gd with all the bling-bling that's in the bundled gd in php, as well as with libzip. The private changes in the bundled libmagic library (file-5.x) is also quite annoying. Previous Comments: [2009-03-27 21:29:40] paj...@php.net Please do not use this report to discuss other topics. But to answer your questions, yes, they are provided as patch upstream as well and we try to keep everything synced as much as possible. But they tend to stay behind for some fixes, especially edge cases for crashes or windows support. You can follow the libzip mailing list if you are interested. [2009-03-27 21:10:56] oeriksson at mandriva dot com Thanks Pierre, What about the private changes in libzip? Will you be able to sync that with upstream as well? [2009-03-27 20:55:35] paj...@php.net There is work being done in libgd.org to bring 2.1.0 out (which should be synced with php). All fixes are done in both libraries (thanks Tabe for taking care of most of them) and many features have made their way. By the way, if the tempo is too slow, you can always give us a hand. I'm not willing to begin again a discussion with the Debian maintainer, I tried many times without success. [2009-03-27 20:40:39] oeriksson at mandriva dot com Excuse me for bothering you with petty issues. Why is it the bundled libgd is not in sync with the more official libgd as you are the sole upstream maintainer? gd hasn't had a new release since 2007-11-28, and none of the bling-bling found in the bundled libgd has found its way into any official libgd release. There are other bundled libraries. What about them then and private changes? [2009-03-27 20:33:12] crrodriguez at opensuse dot org Pierre: is there any summary on what has to be done exactly to sync both libraries so distributions can just ship one copy of libgd ? Maybe all interested parties can hack into it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47812 -- Edit this bug report at http://bugs.php.net/?id=47812edit=1
#47812 [Asn]: undefined symbol: gdJpegGetVersionInt
ID: 47812 Updated by: paj...@php.net Reported By: oeriksson at mandriva dot com Status: Assigned Bug Type: GD related Operating System: Mandriva Linux PHP Version: 5.3.0RC1 Assigned To: pajoye New Comment: The private changes in the bundled libmagic library (file-5.x) is also quite annoying. It will end like mod_mime, to only use the DB. Previous Comments: [2009-03-30 17:38:58] oeriksson at mandriva dot com Thanks Pierre, I'm looking forward to a gd with all the bling-bling that's in the bundled gd in php, as well as with libzip. The private changes in the bundled libmagic library (file-5.x) is also quite annoying. [2009-03-27 21:29:40] paj...@php.net Please do not use this report to discuss other topics. But to answer your questions, yes, they are provided as patch upstream as well and we try to keep everything synced as much as possible. But they tend to stay behind for some fixes, especially edge cases for crashes or windows support. You can follow the libzip mailing list if you are interested. [2009-03-27 21:10:56] oeriksson at mandriva dot com Thanks Pierre, What about the private changes in libzip? Will you be able to sync that with upstream as well? [2009-03-27 20:55:35] paj...@php.net There is work being done in libgd.org to bring 2.1.0 out (which should be synced with php). All fixes are done in both libraries (thanks Tabe for taking care of most of them) and many features have made their way. By the way, if the tempo is too slow, you can always give us a hand. I'm not willing to begin again a discussion with the Debian maintainer, I tried many times without success. [2009-03-27 20:40:39] oeriksson at mandriva dot com Excuse me for bothering you with petty issues. Why is it the bundled libgd is not in sync with the more official libgd as you are the sole upstream maintainer? gd hasn't had a new release since 2007-11-28, and none of the bling-bling found in the bundled libgd has found its way into any official libgd release. There are other bundled libraries. What about them then and private changes? 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/47812 -- Edit this bug report at http://bugs.php.net/?id=47812edit=1
#47832 [Opn-Bgs]: Garbled associative array indices
ID: 47832
Updated by: johan...@php.net
Reported By: r dot borschel at gmx dot net
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: OS X 10.5.6
PHP Version: 5.3CVS-2009-03-29 (snap)
Assigned To: mysql
New Comment:
You might try setting the DYLD_LIBRARY_PATH environment variable to
have the path to mysql first when starting PHP.
What happens is that PHP asks the system's dynamic loader to load
libmysqlclient, the dynamic loader has a list of directories to choose
from and looks for one after another for that file and loads it. See the
dyld(1) and elated manpages for details on that.
Setting to bogus as this is more an issue from the system than PHP.
Previous Comments:
[2009-03-30 15:55:35] r dot borschel at gmx dot net
That's interesting. Here is the output:
$ otool -L sapi/cli/php | grep mysql
/sw/lib/mysql/libmysqlclient.15.dylib (compatibility version 16.0.0,
current version 16.0.0)
So the libmysql getting loaded is from Fink (/sw is the root directory
of Fink). Clearly this is not what I wanted. Here is my complete
configure listing:
'./configure' \
'--prefix=/usr/local/php-5.3' \
'--with-apxs2=/usr/local/apache2.2.9/bin/apxs' \
'--enable-exif' \
'--with-gd' \
'--with-jpeg-dir=/sw' \
'--with-png-dir=/sw' \
'--enable-mbstring' \
'--with-mcrypt=/sw' \
'--with-mhash=/sw' \
'--with-iconv' \
'--with-mysql=/usr/local/mysql-5.1.32-osx10.5-x86' \
'--with-pdo-mysql=/usr/local/mysql-5.1.32-osx10.5-x86' \
'--with-pdo-pgsql=/usr/local/pgsql' \
'--with-pgsql=/usr/local/pgsql/' \
'--with-curl=/sw' \
'--with-zlib-dir=/sw' \
'--enable-soap' \
'--enable-sqlite-utf8' \
'--enable-zip' \
As you can see I'm using Fink libraries for some of the dependencies
but clearly not for mysql. It seems, however, that the Fink libmysql is
chosen anyway for whatever reason (/sw paths are prepended to the $PATH
so maybe that has something to do with it)
It's good to see that this issue is rather caused by a version mess
on my side even though the resulting behavior is a bit scary because it
does not indicate any errors, just garbled results.
Thanks for helping me resolve this issue. As far as I am concerned this
does not seem like a PHP-related issue and I guess unpredictable
behavior is supposed to be expected when using incompatible versions.
Feel free to close this issue if you think it does not deserve any
further attention.
[2009-03-30 14:35:49] johan...@php.net
don't have a mac at hand, if ldd doesn't work try otool -L (which is
part of the developer tools)
[2009-03-30 14:27:23] johan...@php.net
hm, interesting mixup, can you try doing
ldd sapi/cli/php | grep mysql
to see which libmysql is being loaded?
[2009-03-30 12:35:27] r dot borschel at gmx dot net
$ sapi/cli/php --ri pdo_mysql
pdo_mysql
PDO Driver for MySQL = enabled
Client API version = 5.0.38
Thats a bit strange, isnt it? My configure looks like this:
'./configure' \
...
'--with-mysql=/usr/local/mysql-5.1.32-osx10.5-x86' \
'--with-pdo-mysql=/usr/local/mysql-5.1.32-osx10.5-x86' \
...
That version mismatch may be the problem? Am I doing something
obviously wrong?
Thanks for your help.
[2009-03-30 11:44:41] johan...@php.net
Which MySQL server and client library versions are you using? - I
tested using 5.1.31 worked for me:
$ sapi/cli/php --ri pdo_mysql
pdo_mysql
PDO Driver for MySQL = enabled
Client API version = 5.1.31
$ sapi/cli/php bug47832.php
array(4) {
[c0__id]=
string(1) 1
[c0__status]=
string(9) developer
[c0__username]=
string(6) romanb
[c0__name]=
string(5) Roman
}
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/47832
--
Edit this bug report at http://bugs.php.net/?id=47832edit=1
#47840 [Fbk-Bgs]: __call ignored when extending PDO
ID: 47840
Updated by: fel...@php.net
Reported By: oorza2k5 at gmail dot com
-Status: Feedback
+Status: Bogus
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.2.9
New Comment:
It's works. It was fixed days ago. (bug#47769)
Thanks.
Previous Comments:
[2009-03-30 17:30:53] oorza2k5 at gmail dot com
It works as expected in the latest CVS under Windows... I don't have a
non-production Linux install to test with, so if someone else could
verify it's fixed in CVS (under Linux), that'd be great.
[2009-03-30 16:48:36] fel...@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-03-30 16:45:08] oorza2k5 at gmail dot com
Description:
Exact same issue (that was supposedly resolved) as #44425, but now with
a MySQL 5.1 database.
__call() doesn't do anything when extending PDO.
This bug is clearly not fixed.
Reproduce code:
---
Reproduce code:
---
?php
class test extends PDO {
function __call($name, array $args) {
echo Called $name in .__CLASS__.'br';
}
function foo() {
echo Called foo in .__CLASS__.'br';
}
}
$a = new test('mysql:dbname=test;host=localhost','user','pw');
$a-foo();
$a-bar();
?
Expected result:
Called foo in test
Called bar in test
Actual result:
--
Called foo in testbr
Fatal error: Call to undefined method test::bar() in test4.php on line
12
--
Edit this bug report at http://bugs.php.net/?id=47840edit=1
#47799 [Opn-Fbk]: Segfault with Regex
ID: 47799
Updated by: j...@php.net
Reported By: mb at insidetheweb dot de
-Status: Open
+Status: Feedback
Bug Type: PCRE related
-Operating System:
+Operating System: *
PHP Version: 5.2.9
New Comment:
You would find out how to generate the backtrace if you bother
reading the document in the link provided. And you don't need to do
it in web server, CLI is fine too.
Previous Comments:
[2009-03-28 01:29:37] mb at insidetheweb dot de
Sorry, no clue how to get a backtrace on a running system.
This httpd -X does not work. Not even mod_backtrace.
Simply
Download the Text_Wiki with Mediawiki and parse some large Table. You
get the error then yourself. I really doubt its system related.
[2009-03-27 16:16:34] fel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
[2009-03-27 01:09:11] mb at insidetheweb dot de
Description:
When i do this Regex
#^\{\|(.*?)(?:^\|\+(.*?))?(^(?:((?R))|.)*?)^\|}#msi
on larger requests, it causes a seqfault.
You just need to be some chars above some kind of limit and you got the
error.
Reproduce code:
---
http://cvs.php.net/viewvc.cgi/pear/Text_Wiki/Text/Wiki/Parse/Mediawiki/Table.php?revision=1.11view=markup
Its Text_Wiki_Mediawiki.
Expected result:
HTTPD Seqfault
--
Edit this bug report at http://bugs.php.net/?id=47799edit=1
#47809 [Opn-Fbk]: PHP doesn't parse the php.ini file
ID: 47809 Updated by: j...@php.net Reported By: privat at timohummel dot com -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: Gentoo PHP Version: 5.3.0RC1 Assigned To: pajoye New Comment: What exactly is in that file? Previous Comments: [2009-03-27 19:02:25] privat at timohummel dot com I just ran apache with strace to make sure that the php.ini file is actually opened. It is opened, but I'm not sure how to debug if the values are getting parsed and probably overwritten later or if the values in the php.ini file are silently ignored. [2009-03-27 16:11:27] privat at timohummel dot com I rebuilt PHP from the CVS, snapshot http://snaps.php.net/php5.3-200903271530.tar.bz2 (latest snapshot currently available). The issue remains, all php.ini-entries are ignored silently when using the apache2 SAPI. Oddly enough, the CLI SAPI works fine and reads the config file as expected. Here's my configure line: './configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info' '--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64' '--disable-cli' '--with-apxs2=/usr/sbin/apxs2' '--disable-cgi' '--with-config-file-path=/etc/php/apache2-php5' '--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active' '--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar' '--with-curl' '--without-curlwrappers' '--disable-dbase' '--disable-exif' '--without-fbsql' '--disable-fileinfo' '--enable-ftp' '--with-gettext' '--with-gmp' '--disable-hash' '--without-kerberos' '--enable-mbstring' '--with-mcrypt' '--without-mhash' '--without-msql' '--without-mssql' '--with-openssl' '--with-openssl-dir=/usr' '--disable-pcntl' '--with-pgsql' '--disable-posix' '--with-pspell' '--without-recode' '--disable-simplexml' '--disable-shmop' '--with-snmp' '--enable-soap' '--disable-sockets' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--with-tidy' '--enable-wddx' '--disable-xmlreader' '--disable-xmlwriter' '--with-xmlrpc' '--with-xsl' '--enable-zip' '--with-zlib' '--disable-debug' '--enable-dba' '--without-cdb' '--with-db4' '--disable-flatfile' '--with-gdbm' '--disable-inifile' '--without-qdbm' '--with-freetype-dir=/usr' '--with-t1lib=/usr' '--disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--with-gd' '--with-imap' '--with-imap-ssl' '--with-mysql=/usr' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=/usr/bin/mysql_config' '--without-pdo-dblib' '--with-pdo-mysql=/usr' '--without-pdo-odbc' '--with-pdo-pgsql' '--with-pdo-sqlite=/usr' '--with-readline' '--without-libedit' '--without-mm' '--with-sqlite=/usr' '--enable-sqlite-utf8' '--with-sqlite3' [2009-03-27 15:06:54] paj...@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. [2009-03-27 15:02:57] privat at timohummel dot com Description: I just upgraded to PHP 5.3.0-rc1 using a custom ebuild. However, it seems that PHP does not parse (or silently ignore) changes done to the php.ini file. I copied the php.ini-development from the distribution to /etc/php/apache2-php5/php.ini. phpinfo() tells me that the loaded configuration file is /etc/php/apache2-php5/php.ini, in which I also did my changes. I wonder if that has something to do with the new development/production configurations. -- Edit this bug report at http://bugs.php.net/?id=47809edit=1
#44848 [Opn-Fbk]: autoload fails with complex loading scheme
ID: 44848
Updated by: j...@php.net
Reported By: nicolas dot grekas+php at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.*CVS, 6CVS (2009-01-21)
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2009-01-05 20:59:06] pinochet dot pl at gmail dot com
I have the same behavior on 5.3 version and 1.01.2009 Snap UBUNTU 8.10
[2008-11-03 10:49:21] nicolas dot grekas+php at gmail dot com
Doesn't work with windows snaps [2008-Nov-03 08:00:00].
I got exactly the same behavior
[2008-06-05 08:33:59] jille at hexon dot cx
I tried creating a work-around for this.
However, this didn't work:
So class B is half-existent ?
You can not define it, but it also doesn't exists...
?php
function __autoload($class)
{
switch ($class)
{
case 'A':
case 'B':
if(class_exists('B', false))
return;
class B extends C {};
break;
case 'C':
class C {};
class A extends B {};
break;
}
}
echo (int) class_exists('A');
?
[2008-04-27 21:22:46] nicolas dot grekas+php at gmail dot com
Description:
Hard to explain, see code... I think that PHP should be able to handle
this kind of loading scheme.
Here is what I thought this code would do :
1. __autoload('A') is called
2. inside this call for A:
2.1 class B is defined, which extends C
2.2 as C is not defined, __autoload('C') is called
2.3 inside this call for C:
2.3.1 class C is defined
2.3.2 (now we have everything needed for class B, haven't we ?)
2.3.3 class A extends B
2.4 we leave the __autoload('C') context
3. we leave the __autoload('A') context
The bug is at step 2.3.3 : class A extends B triggers an
autoload('B'), which should not occurs, as B should be already defined,
thanks to 2.3.2...
Reproduce code:
---
?php
function __autoload($class)
{
switch ($class)
{
case 'A':
case 'B':
class B extends C {};
break;
case 'C':
class C {};
class A extends B {};
break;
}
}
echo (int) class_exists('A');
Expected result:
1
Actual result:
--
Fatal error: Cannot redeclare class B in [...] on line 9
--
Edit this bug report at http://bugs.php.net/?id=44848edit=1
#47828 [Csd]: Seg Fault in openssl_x509_parse
ID: 47828 Updated by: paj...@php.net Reported By: reinke at securityspace dot com Status: Closed Bug Type: OpenSSL related Operating System: Linux (Debian Lenny) PHP Version: 5.2.9 Assigned To: scottmac New Comment: For the record here, if you use ubuntu you can follow this issue here: https://bugs.launchpad.net/bugs/351730 I also updated the test case using the one from Kees Cook as it covers more architectures (incl. the intel ones I have here, and that's nice :). Previous Comments: [2009-03-30 14:55:40] paj...@php.net Note that even people from Ubuntu security were not able to reproduce it (I asked them to take a look at the report). So excuse me but there were doubts about this bug, like it or not. And that's why I asked you to test with our src, you did, thanks. Also I did not ask you to do not use the distribution version of php but to use our sources to see if the bug can be reproduced. It is common practice to ask that, not only in php. [2009-03-30 14:43:12] reinke at securityspace dot com No, our official distributions channel is http://www.php.net/downloads and http://windows.php.net, nothing else. Pierre - that's wishful thinking and a pile of crock. Argue over the semantics of official however you wish. The reality, however, is that about 28% of all web sites with PHP are known to be using a Distro version of PHP. And of the remaining 72%, we can't even say they are using a version from your web site, only that we don't know if they are using your version, or one from a distro. Don't get me wrong - your (PHP's) fix time on this was absolutely amazing, and to repeat, we have no issue with helping out on a problem. But telling folks not to use a distro version of PHP is just not in line with reality. And for the record - every 5.2.x install we've touched on a Linux box was vulnerable. If you couldn't reproduce on Ubuntu or Debian using the concise 3 line script provided after several hours of our digging to make it easy on you, perhaps you need to have a broader range of hardware to check on. Every x86 based install WE checked on 5.2.x was vulnerable and reproduced the problem. INCLUDING your latest snapshot. Grumble - you ought to take this thread and mark it as a how to take a customer that was willing to help find a bug that crashes your application and really piss him off. Scott - thanks for the quick fix. Above and beyond. Thomas [2009-03-30 09:59:49] paj...@php.net Firt, I do not care if it took 0.5 second or 3 hours. Secondly, the bug is less than a day old, we did run test and it did not crash on all platforms I can test (windows, ubuntu x64/x86 and debian). So not it was not obvious that there was a real bug in the current code. And finally, you can't know if a) there is already a patch or a fix and b) what's the status, simply because you did not bother to ask. There is no problem to take over any bug as long as you simply ask before. It will save us time and pains (as in this kind of discussions, which happen only with you). Thanks for your understanding and your work. [2009-03-30 09:24:43] scott...@php.net Pierre using the test given by the reporter I could reproduce this, took less than a minute to find the issue. Assigning yourself a bug that you'll look at next week isn't all that useful, especially if someone with more time comes along in that next week. Perhaps we need to add multiple assignment to bugs? FYI OpenSSL verions OpenSSL 0.9.7l 28 Sep 2006 (OS X default) OpenSSL 0.9.8j 07 Jan 2009 [2009-03-30 06:00:06] paj...@php.net With all due respect - we are using PHP's official release. On Debian. As provided by the distro. On Ubuntu. As provided by Ubuntu. On Fedora. As provided by... well, you get it. Like it or not, these vendors are your distribution channel No, our official distributions channel is http://www.php.net/downloads and http://windows.php.net, nothing else. Distributions, in their majority, do a great job at distributing php but they are not our official releases channel, especially not when they use unofficial patches like suhosin or other random changes. The reason we ask to try PHP's version is to be sure about the src of the problem, we have no control over what the distros do or don't. 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/47828 -- Edit this bug report at http://bugs.php.net/?id=47828edit=1
#47809 [Fbk-Opn]: PHP doesn't parse the php.ini file
ID: 47809 User updated by: privat at timohummel dot com Reported By: privat at timohummel dot com -Status: Feedback +Status: Open Bug Type: PHP options/info functions Operating System: Gentoo PHP Version: 5.3.0RC1 Assigned To: pajoye New Comment: It is the stock php.ini-development file, where I tried to set the default timezone to Europe/Berlin. As it didn't work, I reverted my change of the timezone and tried modifying other values, for example, the error reporting and also simple values like precision. None of my changes were shown after a restart of apache using the phpinfo()-call. As I said before, changes are accepted when using the cli sapi. Previous Comments: [2009-03-30 18:07:19] j...@php.net What exactly is in that file? [2009-03-27 19:02:25] privat at timohummel dot com I just ran apache with strace to make sure that the php.ini file is actually opened. It is opened, but I'm not sure how to debug if the values are getting parsed and probably overwritten later or if the values in the php.ini file are silently ignored. [2009-03-27 16:11:27] privat at timohummel dot com I rebuilt PHP from the CVS, snapshot http://snaps.php.net/php5.3-200903271530.tar.bz2 (latest snapshot currently available). The issue remains, all php.ini-entries are ignored silently when using the apache2 SAPI. Oddly enough, the CLI SAPI works fine and reads the config file as expected. Here's my configure line: './configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info' '--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64' '--disable-cli' '--with-apxs2=/usr/sbin/apxs2' '--disable-cgi' '--with-config-file-path=/etc/php/apache2-php5' '--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active' '--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar' '--with-curl' '--without-curlwrappers' '--disable-dbase' '--disable-exif' '--without-fbsql' '--disable-fileinfo' '--enable-ftp' '--with-gettext' '--with-gmp' '--disable-hash' '--without-kerberos' '--enable-mbstring' '--with-mcrypt' '--without-mhash' '--without-msql' '--without-mssql' '--with-openssl' '--with-openssl-dir=/usr' '--disable-pcntl' '--with-pgsql' '--disable-posix' '--with-pspell' '--without-recode' '--disable-simplexml' '--disable-shmop' '--with-snmp' '--enable-soap' '--disable-sockets' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--with-tidy' '--enable-wddx' '--disable-xmlreader' '--disable-xmlwriter' '--with-xmlrpc' '--with-xsl' '--enable-zip' '--with-zlib' '--disable-debug' '--enable-dba' '--without-cdb' '--with-db4' '--disable-flatfile' '--with-gdbm' '--disable-inifile' '--without-qdbm' '--with-freetype-dir=/usr' '--with-t1lib=/usr' '--disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--with-gd' '--with-imap' '--with-imap-ssl' '--with-mysql=/usr' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=/usr/bin/mysql_config' '--without-pdo-dblib' '--with-pdo-mysql=/usr' '--without-pdo-odbc' '--with-pdo-pgsql' '--with-pdo-sqlite=/usr' '--with-readline' '--without-libedit' '--without-mm' '--with-sqlite=/usr' '--enable-sqlite-utf8' '--with-sqlite3' [2009-03-27 15:06:54] paj...@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. [2009-03-27 15:02:57] privat at timohummel dot com Description: I just upgraded to PHP 5.3.0-rc1 using a custom ebuild. However, it seems that PHP does not parse (or silently ignore) changes done to the php.ini file. I copied the php.ini-development from the distribution to /etc/php/apache2-php5/php.ini. phpinfo() tells me that the loaded configuration file is /etc/php/apache2-php5/php.ini, in which I also did my changes. I wonder if that has something to do with the new development/production configurations. -- Edit this bug report at http://bugs.php.net/?id=47809edit=1
#47745 [Asn]: FILTER_VALIDATE_INT doesn't allow minimum integer
ID: 47745 Updated by: il...@php.net Reported By: for-bugs at hnw dot jp Status: Assigned Bug Type: Filter related Operating System: * PHP Version: 5.2.9 -Assigned To: iliaa +Assigned To: dmitry New Comment: The multiplication is done by the standard ZEND macro, so if there is a limit issue it needs to be handled inside the Zend Engine. That said on my 64bit machine, I cannot reproduce the issue via - PHP_INT_MAX Previous Comments: [2009-03-29 21:38:18] scott...@php.net Must have been sleep deprived when I looked at this last. [2009-03-29 16:47:47] paj...@php.net The only problem is the value we use for the max unsigned range. It should be changed to allow - 2^31, but I did not check the code more in details, but Ilia is on it so :) [2009-03-29 16:43:23] il...@php.net We don't eat a 0. When parsing #s we follow this logic: Let's say X is our temp var containing the 1st digit and the number to be parsed is 435. X = X * 10; X += 3; (X = 43) X = X * 10; X += 5; (X = 435) There is no 0 eating etc... [2009-03-26 22:44:17] scott...@php.net For some reason php_filter_parse_int multiplies the integer by ten then attempts to eat a 0? This is causing overflow and resulting in an error. I have no idea why its doing this though. ilia? [2009-03-21 23:34:01] for-bugs at hnw dot jp Description: Although -2147483648 is the minimum integer in 32bit environment, FILTER_VALIDATE_INT says -2147483648 is invalid as integer. Reproduce code: --- ?php var_dump(intval(-2147483648)); var_dump(filter_var(-2147483648, FILTER_VALIDATE_INT)); Expected result: int(-2147483648) int(-2147483648) Actual result: -- int(-2147483648) bool(false) -- Edit this bug report at http://bugs.php.net/?id=47745edit=1
#47831 [Opn-Csd]: Compile warning for strnlen() in main/spprintf.c (missing #define _GNU_SOURCE)
ID: 47831 Updated by: il...@php.net Reported By: rainer dot jung at kippdata dot de -Status: Open +Status: Closed Bug Type: Compile Warning Operating System: Linux PHP Version: 5.2.9 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-03-29 20:00:38] rainer dot jung at kippdata dot de Description: PHP 5.2.9 does auto detection for strnlen(). On Linux the detection results in strnlen() availability. The function is only available, when _GNU_SOURCE is defined though. File main/spprintf.c uses it without _GNU_SOURCE in PHP 5.2.9. This is due to an incomplete backport from MAIN and 5.3. See http://cvs.php.net/viewvc.cgi/php-src/main/spprintf.c?r1=1.25.2.2.2.10.2.4r2=1.25.2.2.2.10.2.5 and http://cvs.php.net/viewvc.cgi/php-src/main/spprintf.c?r1=1.53r2=1.54; and compare with http://cvs.php.net/viewvc.cgi/php-src/main/spprintf.c?r1=1.25.2.2.2.14r2=1.25.2.2.2.15 Patch: --- main/spprintf.c 2009-02-04 16:03:12.0 +0100 +++ main/spprintf.c 2009-03-29 21:58:10.0 +0200 @@ -76,6 +76,7 @@ * SIO stdio-replacement strx_* functions by Panos Tsirigotis * pa...@alumni.cs.colorado.edu for xinetd. */ +#define _GNU_SOURCE #include php.h #include stddef.h -- Edit this bug report at http://bugs.php.net/?id=47831edit=1
#13421 [Com]: Problematic MIME-Type application/x-httpd-php
ID: 13421 Comment by: earthmagik at sbcglobal dot net Reported By: php at matthias-wimmer dot de Status: No Feedback Bug Type: Apache related Operating System: Linux PHP Version: 4.0.6 New Comment: What the H*** is the problem??? I have never had this before, and do not wantit again!!! Previous Comments: [2009-02-04 21:55:41] akms_77 at hotmail dot com Kqcs [2008-12-11 18:51:25] JAMALMNK at HOTMAIL dot COM JAMAL [2003-03-14 06:15:37] bartek at luka dot dagma dot pl It seems like the same problem occurs in 4.3.1 version of PHP running on Apache 1.3.x. [2002-12-23 16:03:27] j dot westendorp at chello dot nl I have the same problem: I can't view my Multiviewed pages (e.g. http://domain.com/news/38 instead of http://domain.com/news.php?ID=38 ) with a user agent that does not send the Accept: */* request header (like AvantGo 3.2 does) because Apache throws a 406 No Acceptable Variant error. I'm running PHP 4.2.2 on Apache 1.3.19 (Red-Hat/Linux) [2002-10-16 01:00:06] php-bugs at lists dot php dot net No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. 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/13421 -- Edit this bug report at http://bugs.php.net/?id=13421edit=1
#47842 [NEW]: sscanf does not support 64-bit values
From: signe at cothlamadh dot net Operating system: FreeBSD 64-bit, Linux 64-bit PHP version: 5.2.9 PHP Bug Type: Unknown/Other Function Bug description: sscanf does not support 64-bit values Description: On 64-bit operating systems, printf()'s %d and %u formatting codes support 64-bit integers. sscanf, which supposedly uses the same code (and has the same expected behavior) does not support 64-bit values. Also, printf is not outputting accurate values when it reaches numbers near the upper bounds of a 64-bit int. Reproduce code: --- ?php sscanf(2147483647, '%d', $int); echo sscanf 32-bit signed int '2147483647' (2^31)-1 = ,$int,\n; sscanf(4294967295, '%u', $int); echo sscanf 32-bit unsign int '4294967295' (2^32)-1 = ,$int,\n; sscanf(9223372036854775807, '%d', $int); echo sscanf 64-bit signed int '9223372036854775807' (2^63)-1 = ,$int,\n; sscanf(18446744073709551615, '%u', $int); echo sscanf 64-bit unsign int '18446744073709551615' (2^64)-1 = ,$int,\n; printf(printf 64-bit signed int '9223372036854775807' (2^63)-1 = %d\n, 9223372036854775807); printf(printf 64-bit signed int '18446744073709551615' (2^64)-1 = %u\n, 18446744073709551615); echo \n(2^64)-1 - 100,000,000\n; printf(printf 64-bit signed int '18446744073609551615' = %u\n, 18446744073609551615); echo Output is 257 greater than input\n; ? Expected result: sscanf 32-bit signed int '2147483647' (2^31)-1 = 2147483647 sscanf 32-bit unsign int '4294967295' (2^32)-1 = 4294967295 sscanf 64-bit signed int '9223372036854775807' (2^63)-1 = 9223372036854775807 sscanf 64-bit unsign int '18446744073709551615' (2^64)-1 = 18446744073709551615 printf 64-bit signed int '9223372036854775807' (2^63)-1 = 9223372036854775807 printf 64-bit signed int '18446744073709551615' (2^64)-1 = 18446744073709551615 Actual result: -- sscanf 32-bit signed int '2147483647' (2^31)-1 = 2147483647 sscanf 32-bit unsign int '4294967295' (2^32)-1 = 4294967295 sscanf 64-bit signed int '9223372036854775807' (2^63)-1 = -1 sscanf 64-bit unsign int '18446744073709551615' (2^64)-1 = 4294967295 printf 64-bit signed int '9223372036854775807' (2^63)-1 = 9223372036854775807 printf 64-bit signed int '18446744073709551615' (2^64)-1 = 0 printf 64-bit signed int '18446744073609551615' ((2^64)-1 - 1) = 18446744073609551872 Output is 257 greater than input -- Edit bug report at http://bugs.php.net/?id=47842edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47842r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47842r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47842r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47842r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47842r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47842r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47842r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47842r=needscript Try newer version: http://bugs.php.net/fix.php?id=47842r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47842r=support Expected behavior: http://bugs.php.net/fix.php?id=47842r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47842r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47842r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47842r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47842r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47842r=dst IIS Stability: http://bugs.php.net/fix.php?id=47842r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47842r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47842r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47842r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47842r=mysqlcfg
#47815 [Asn]: Compile time computation of hash value decrease hash lookup time.
ID: 47815
User updated by: basant dot kukreja at gmail dot com
Reported By: basant dot kukreja at gmail dot com
Status: Assigned
Bug Type: Performance problem
Operating System: Solaris 10
PHP Version: 5.2.9
Assigned To: dmitry
New Comment:
Regarding adding new field in opcode :
Ideally I think it would be best if we could have used
extended_value for
the hash value but some of the relevant opcodes were already using this
field.
I understand that adding one field in opcode can cause reduction in
performance in some scenarios.
Other possible solutions which come to my mind is (which is kind of
hack):
* Encode hash value inside string e.g
zval.value.str.val = abc\0hash_value
zval.value.str.len = 3
-
Regarding using zend_std_read_property_hval :
Ideally I would like to add a parameter in zend_std_read_property
but it
would break other object handlers. One possibility is to add a
function
pointer in _zend_object_handlers e.g
typedef zval *(*zend_object_read_property_hash_t)(zval *object, zval
*member, hlong hval, int type TSRMLS_DC);
struct _zend_object_handlers {
...
zend_object_read_property_hash_t
read_property_hash;
};
And then in opcode handler, we can write :
if ((OP2_TYPE == IS_CONST)
Z_OBJ_HT_P(container)-read_property_hash)
{
*retval =
Z_OBJ_HT_P(container)-read_property_hash(container,
offset,
EX(opline)-hval,
type TSRMLS_CC);
} else {
*retval =
Z_OBJ_HT_P(container)-read_property(container, offset,
type TSRMLS_CC);
}
Previous Comments:
[2009-03-30 12:48:04] dmi...@php.net
I like the idea, but I don't like some implementation details (addition
field in zend_opcode, tricky zend_std_read_property_hash() invocation).
However, I know that it's probably not possible to do it better.
I would like to make some benchmark tests, but the patch is broken.
Could you please put the patch somewhere or send it by email.
[2009-03-27 23:02:12] basant dot kukreja at gmail dot com
Some signifiant percentage of the time is spent in calculating the hash
value
of string contants.
If we compute the hash value of string constants during compilation
then
lookup time can be improved a lot.
With the above submitted patch results are better :
Excl. Incl. Name
User CPU User CPU
sec. sec.
414.450 726.638 zend_fetch_dimension_address
74.922238.016 zend_get_property_info_hval
Note the 150 second (~20 % time) less time spent in
zend_fetch_dimension_address and 190 second (45% time) reduction in
zend_get_property_info.
It showed 1% performance overall.
[2009-03-27 22:59:55] basant dot kukreja at gmail dot com
diff -r 00438f7eebe4 php-5.2.9RC3/Zend/zend_compile.h
--- a/php-5.2.9RC3/Zend/zend_compile.h Tue Mar 17 11:27:02 2009 -0700
+++ b/php-5.2.9RC3/Zend/zend_compile.h Fri Mar 27 10:18:13 2009 -0700
@@ -83,6 +83,7 @@
znode op1;
znode op2;
ulong extended_value;
+ ulong hval;
uint lineno;
zend_uchar opcode;
};
diff -r 00438f7eebe4 php-5.2.9RC3/Zend/zend_execute.c
--- a/php-5.2.9RC3/Zend/zend_execute.c Tue Mar 17 11:27:02 2009 -0700
+++ b/php-5.2.9RC3/Zend/zend_execute.c Fri Mar 27 10:18:13 2009 -0700
@@ -930,11 +930,12 @@
return NULL;
}
-static inline zval **zend_fetch_dimension_address_inner(HashTable *ht,
zval *dim, int type TSRMLS_DC)
+static inline zval **zend_fetch_dimension_address_inner(HashTable *ht,
zval *dim, int type, zend_ulong hval, int usehval TSRMLS_DC)
{
zval **retval;
char *offset_key;
int offset_key_length;
+ int ret;
switch (dim-type) {
case IS_NULL:
@@ -948,7 +949,13 @@
offset_key_length = dim-value.str.len;
fetch_string_dim:
- if (zend_symtable_find(ht, offset_key,
offset_key_length+1, (void
**) retval) == FAILURE) {
+ if (usehval) {
+ ret = zend_symtable_quick_find(ht, offset_key,
offset_key_length+1, hval, (void **) retval);
+ }
+ else {
+ ret = zend_symtable_find(ht, offset_key,
offset_key_length+1,
(void **) retval);
+ }
+ if (ret == FAILURE) {
switch (type) {
#47842 [Opn]: sscanf does not support 64-bit values
ID: 47842 User updated by: signe at cothlamadh dot net Reported By: signe at cothlamadh dot net Status: Open Bug Type: Unknown/Other Function Operating System: FreeBSD 64-bit, Linux 64-bit PHP Version: 5.2.9 New Comment: Note: sscanf %x and %X have the same behavior as %d and %u Previous Comments: [2009-03-30 21:26:23] signe at cothlamadh dot net Description: On 64-bit operating systems, printf()'s %d and %u formatting codes support 64-bit integers. sscanf, which supposedly uses the same code (and has the same expected behavior) does not support 64-bit values. Also, printf is not outputting accurate values when it reaches numbers near the upper bounds of a 64-bit int. Reproduce code: --- ?php sscanf(2147483647, '%d', $int); echo sscanf 32-bit signed int '2147483647' (2^31)-1 = ,$int,\n; sscanf(4294967295, '%u', $int); echo sscanf 32-bit unsign int '4294967295' (2^32)-1 = ,$int,\n; sscanf(9223372036854775807, '%d', $int); echo sscanf 64-bit signed int '9223372036854775807' (2^63)-1 = ,$int,\n; sscanf(18446744073709551615, '%u', $int); echo sscanf 64-bit unsign int '18446744073709551615' (2^64)-1 = ,$int,\n; printf(printf 64-bit signed int '9223372036854775807' (2^63)-1 = %d\n, 9223372036854775807); printf(printf 64-bit signed int '18446744073709551615' (2^64)-1 = %u\n, 18446744073709551615); echo \n(2^64)-1 - 100,000,000\n; printf(printf 64-bit signed int '18446744073609551615' = %u\n, 18446744073609551615); echo Output is 257 greater than input\n; ? Expected result: sscanf 32-bit signed int '2147483647' (2^31)-1 = 2147483647 sscanf 32-bit unsign int '4294967295' (2^32)-1 = 4294967295 sscanf 64-bit signed int '9223372036854775807' (2^63)-1 = 9223372036854775807 sscanf 64-bit unsign int '18446744073709551615' (2^64)-1 = 18446744073709551615 printf 64-bit signed int '9223372036854775807' (2^63)-1 = 9223372036854775807 printf 64-bit signed int '18446744073709551615' (2^64)-1 = 18446744073709551615 Actual result: -- sscanf 32-bit signed int '2147483647' (2^31)-1 = 2147483647 sscanf 32-bit unsign int '4294967295' (2^32)-1 = 4294967295 sscanf 64-bit signed int '9223372036854775807' (2^63)-1 = -1 sscanf 64-bit unsign int '18446744073709551615' (2^64)-1 = 4294967295 printf 64-bit signed int '9223372036854775807' (2^63)-1 = 9223372036854775807 printf 64-bit signed int '18446744073709551615' (2^64)-1 = 0 printf 64-bit signed int '18446744073609551615' ((2^64)-1 - 1) = 18446744073609551872 Output is 257 greater than input -- Edit this bug report at http://bugs.php.net/?id=47842edit=1
#47724 [Com]: Reproducable segmenation fault using symfony and doctrine
ID: 47724 Comment by: scott at danielfamily dot com Reported By: scott at danielfamily dot com Status: No Feedback Bug Type: Reproducible crash Operating System: Centos 5.2 PHP Version: 5.2.9 New Comment: Scott MacVicar from the PHP team send me a note saying he would look at the bug. I uploaded the VMWARE appliance and send him the information, but have not heard back after some days. Still hoping for some love. Previous Comments: [2009-03-31 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-03-23 19:14:17] scott at danielfamily dot com Thanks for the quick response. I understand that infinite recursion is a sure way to crash PHP. I've fixed those problems a bunch of times over the years. However, those bugs tend to manifest themselves in a consistent way. In this situation, removing code that is not even executed can cause the problem to disappear. Adding a few random instructions can also make the problem disappear. This would not happen if there was a recursion problem. This really feels like a heap corruption or some other wickedness in code A is causing a crash in code B where A and B are basically unrelated. These are REALLY REALLY hard to find and fix so I am sympathetic to your reluctance to dive in, but I believe this is a real problem. I've posted a ticket with the symfony team and hope that someone will respond (http://trac.symfony-project.org/ticket/6152), but as I say in that ticket, I believe the problem is with PHP, not symfony or doctrine. The symfony/doctrine stack simply represents the proper level of complexity to cause the PHP failure. Part of my persistence is that I believe it is very possible that this is related to Bug #40479 (http://bugs.php.net/bug.php?id=40479). I have some very negative experience with this problem on another project where my team spent nearly a man-month trying to find a random heap corruption problem. We ended up abandoning the Smarty based project and using Symfony with good results. In that case the problem was consistent, but intermittent. In this case, the problem is consistent and reproducible. [2009-03-23 18:08:14] ras...@php.net Are you sure this isn't a circular reference causing some sort of infinite recursion? There is no protection against infinite recursion crashes in 5.2.x [2009-03-23 17:56:13] scott at danielfamily dot com I believe very strongly that this is a bug in PHP, not in doctrine or symfony. Modifying seemingly random and benign pieces of code, changing the order of code, or collapsing classes usually results in the problem disappearing. This makes it impossible to comply with your request for a simple script. This is VERY likely to be a corrupt heap situation that only manifests itself when the planets are aligned correctly. I have gotten those planets to align consistently and the crash always happens. I'm willing to do anything reasonable to get someone to look at this problem. Building the VMWARE appliance seemed like the best approach as it will allow someone familiar with the internals of PHP to download the appliance and duplicate the problem in minutes. I've already posted this on the symfony forums and gotten sympathy, but no substitive suggestions. I'll try posting it as a symfony bug and see what happens. [2009-03-22 18:00:09] paj...@php.net If you are not able to create a self contained script to reproduce the problem, report the bug to symfony or doctrine developers and ask them to analyze it. We can't use these tools as a base to debug this issue. Thanks for your understanding. 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/47724 -- Edit this bug report at http://bugs.php.net/?id=47724edit=1
