#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=47828&edit=1
#47828 [Csd->Opn]: Seg Fault in openssl_x509_parse
ID: 47828 Updated by: paj...@php.net Reported By: reinke at securityspace dot com -Status: Closed +Status: Open Bug Type: OpenSSL related Operating System: Linux (Debian Lenny) PHP Version: 5.2.9 Assigned To: pajoye New Comment: Scott, that's nice but add a test please with the data you use to reproduce the segfault. Previous Comments: [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. [2009-03-29 21:51:18] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47828 -- Edit this bug report at http://bugs.php.net/?id=47828&edit=1
#47835 [NEW]: strtotime or date works wrong
From: snowyurik at gmail dot com
Operating system: Linux
PHP version: 5.2.9
PHP Bug Type: Date/time related
Bug description: strtotime or date works wrong
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 bug report at http://bugs.php.net/?id=47835&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47835&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47835&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47835&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47835&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47835&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47835&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47835&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47835&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47835&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47835&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47835&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47835&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47835&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47835&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47835&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47835&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47835&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47835&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47835&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47835&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47835&r=mysqlcfg
#47834 [NEW]: tempnam() changes to %TEMP% instead of returning false
From: whistl0r+phpbug at googlemail dot com Operating system: Windows PHP version: 5.2.9 PHP Bug Type: Filesystem function related Bug description: tempnam() changes to %TEMP% instead of returning false Description: I wanted to check, how tempnam() handles file system limits. On NTFS, just 65535 files per directory are allowed. Reproduce code: --- http://bugs.php.net/?id=47834&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47834&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47834&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47834&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47834&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47834&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47834&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47834&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47834&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47834&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47834&r=support Expected behavior: http://bugs.php.net/fix.php?id=47834&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47834&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47834&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47834&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47834&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47834&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47834&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47834&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47834&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47834&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47834&r=mysqlcfg
#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: pajoye New Comment: Also reproduced on Lenny using snapshot php5.2-200903292230. ./configure --with-openssl make sapi/cli/php ~/core2.php -> segmentation fault. Previous Comments: [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. [2009-03-29 21:51:18] paj...@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-29 21:51:04] paj...@php.net Thanks for testing all these distributions but it is not what I was asking. Please use PHP.net's sources, available in our downloads page, snapshots via cvs. See my next comment for the snapshot links. [2009-03-29 21:50:43] reinke at securityspace dot com Updated OS' impacted. 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=47828&edit=1
#47828 [Csd]: Seg Fault in openssl_x509_parse
ID: 47828 Updated by: scott...@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: pajoye New Comment: I fixed it about 10 minutes ago, the snapshot is from a few hours ago. Previous Comments: [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. [2009-03-29 21:51:18] paj...@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-29 21:51:04] paj...@php.net Thanks for testing all these distributions but it is not what I was asking. Please use PHP.net's sources, available in our downloads page, snapshots via cvs. See my next comment for the snapshot links. 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=47828&edit=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: pajoye 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. The string tried to decode one of the items to utf-8 and it failed, this wasn't properly checked resulting in a segfault. Previous Comments: [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. [2009-03-29 21:51:18] paj...@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-29 21:51:04] paj...@php.net Thanks for testing all these distributions but it is not what I was asking. Please use PHP.net's sources, available in our downloads page, snapshots via cvs. See my next comment for the snapshot links. [2009-03-29 21:50:43] reinke at securityspace dot com Updated OS' impacted. [2009-03-29 21:48:55] reinke at securityspace dot com Further testing has confirmed this is reproducible on a variety of Linux distributions. Some of these have been tested with virgin (installed from ISOs, but no updates applied) configurations, some with fully up to date (all updates applied). Confirmed as reproducible: Distro PHP version - Debian 5.0 5.2.6-1+lenny2 Ubuntu 8.10 PHP 5.2.6-2ubuntu4.1 with Suhosin-Patch 0.9.6.2 Fedora Core 10 PHP 5.2.6 Slackware 12.1 PHP 5.2.5 Gentoo PHP 5.2.6-r7 (old version), 5.2.8-r2 (up to date) Debian 5.0 systems are fully up to date. Ubuntu 8.10 tested 2 setups, both seg faulted. - Setup 1: Latest PHP, ISO version of OpenSSL - Setup 2: Fully updated system Fedora Core 10 - tested both on virgin setup as well as fully up to date systems. Both setups segfaulted. Slackware - only virgin setup tested. Gentoo - 5.2.6-r7 - known out of date. 5.2.8-r2 involved a sync and rebuild of openssl and php along with a few other packages. Both seg faulted. On vulnerable systems, running "openssl x509 -inform PEM -in badcert.pem -text" where the signed pub key provided earlier is in "badcert.pem" (with \n markers appropriately changed to newline) spits out all information in the cert without any apparent problems. The Unbutu 8.10 gdb backtrace is typical of of the systems we tested (we stopped checking backtraces after Deb, Ubuntu, FC10 all produced the same thing) # gdb php (gdb) r core2.php Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb78088e0 (LWP 4011)] 0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0x in ?? () #2 0x082dea85 in add_next_index_stringl () #3 0x0809df90 in ?? () #4 0x0809e23a in zif_openssl_x509_parse () #5 0x08313f23 in ?? () #6 0x082ff3bb in execute () If you really think our SSL packages were out of date, we can provide that info. But we're pretty sure that in situations where we said we're fully up to date, that we were. We're aware we could install PHP from sources directly from php.net, but for maintenance reasons _really_ want to use the distro's packages. ALL of the above testing was using the distro's prepackaged software. We could NOT reproduce this on: CentOS 5.1 (php 5.1.6-20.el5_2.1) RedHat 5.2 (php 5.1.6-2
#47828 [Opn]: Seg Fault in openssl_x509_parse
ID: 47828 User updated by: reinke at securityspace dot com 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, 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. Previous Comments: [2009-03-29 21:51:18] paj...@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-29 21:51:04] paj...@php.net Thanks for testing all these distributions but it is not what I was asking. Please use PHP.net's sources, available in our downloads page, snapshots via cvs. See my next comment for the snapshot links. [2009-03-29 21:50:43] reinke at securityspace dot com Updated OS' impacted. [2009-03-29 21:48:55] reinke at securityspace dot com Further testing has confirmed this is reproducible on a variety of Linux distributions. Some of these have been tested with virgin (installed from ISOs, but no updates applied) configurations, some with fully up to date (all updates applied). Confirmed as reproducible: Distro PHP version - Debian 5.0 5.2.6-1+lenny2 Ubuntu 8.10 PHP 5.2.6-2ubuntu4.1 with Suhosin-Patch 0.9.6.2 Fedora Core 10 PHP 5.2.6 Slackware 12.1 PHP 5.2.5 Gentoo PHP 5.2.6-r7 (old version), 5.2.8-r2 (up to date) Debian 5.0 systems are fully up to date. Ubuntu 8.10 tested 2 setups, both seg faulted. - Setup 1: Latest PHP, ISO version of OpenSSL - Setup 2: Fully updated system Fedora Core 10 - tested both on virgin setup as well as fully up to date systems. Both setups segfaulted. Slackware - only virgin setup tested. Gentoo - 5.2.6-r7 - known out of date. 5.2.8-r2 involved a sync and rebuild of openssl and php along with a few other packages. Both seg faulted. On vulnerable systems, running "openssl x509 -inform PEM -in badcert.pem -text" where the signed pub key provided earlier is in "badcert.pem" (with \n markers appropriately changed to newline) spits out all information in the cert without any apparent problems. The Unbutu 8.10 gdb backtrace is typical of of the systems we tested (we stopped checking backtraces after Deb, Ubuntu, FC10 all produced the same thing) # gdb php (gdb) r core2.php Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb78088e0 (LWP 4011)] 0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0x in ?? () #2 0x082dea85 in add_next_index_stringl () #3 0x0809df90 in ?? () #4 0x0809e23a in zif_openssl_x509_parse () #5 0x08313f23 in ?? () #6 0x082ff3bb in execute () If you really think our SSL packages were out of date, we can provide that info. But we're pretty sure that in situations where we said we're fully up to date, that we were. We're aware we could install PHP from sources directly from php.net, but for maintenance reasons _really_ want to use the distro's packages. ALL of the above testing was using the distro's prepackaged software. We could NOT reproduce this on: CentOS 5.1 (php 5.1.6-20.el5_2.1) RedHat 5.2 (php 5.1.6-20.el5) [2009-03-29 17:20:16] paj...@php.net Can't reproduce on Ubuntu 8.10, windows or latest debian (using PHP sources). I would suggest to first see if you have the latest openssl (openssl debian's package contains the latest fixes) install. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug re
#47829 [Opn]: Segmentation fault on startup with PDO Firebird compiled in
ID: 47829
User updated by: info at programmiernutte dot net
Reported By: info at programmiernutte dot net
Status: Open
Bug Type: Reproducible crash
Operating System: Debian Etch x86_64
PHP Version: 5.3.0RC1
New Comment:
I did some more experimenting, and I figured that the Crash does not
occur when PDO Firebird is compiled as a shared module and loaded as
extension. PDO Extension seems to work.
Previous Comments:
[2009-03-29 16:11:42] info at programmiernutte dot net
Description:
I am getting Segmentation fault on startup, no matter if SAPI apache 2
or CLI. Same Version of PHP and same Firebird Version (2.1.1.) are
running flawlessly on my G4 Mac on Mac OS X 10.4.11, so maybe this is
64bit-related?
I used gdb to track this down to PDO Firebird Initialisation Startup:
(gdb) run
Starting program: /usr/src/php-5.3.0RC1/sapi/cli/php
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread 47013927445712 (LWP 16824)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47013927445712 (LWP 16824)]
zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
3210if (ce->type & ZEND_INTERNAL_CLASS) {
(gdb) where
#0 zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
#1 0x005190c2 in zm_startup_pdo_firebird (type=, module_number=)
at /usr/src/php-5.3.0RC1/ext/pdo_firebird/pdo_firebird.c:58
#2 0x0061cfbe in zend_startup_module_ex (module=0xcafb10) at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1593
#3 0x00625f05 in zend_hash_apply (ht=0xc62e80,
apply_func=0x61cec0 )
at /usr/src/php-5.3.0RC1/Zend/zend_hash.c:673
#4 0x0061d89a in zend_startup_modules () at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1642
#5 0x005c827f in php_module_startup (sf=,
additional_modules=0x0, num_additional_modules=0)
at /usr/src/php-5.3.0RC1/main/main.c:1952
#6 0x006a0e5d in php_cli_startup (sapi_module=0x0) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:370
#7 0x006a155f in main (argc=1, argv=0x7fff63c23928) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:742
--
Edit this bug report at http://bugs.php.net/?id=47829&edit=1
#47828 [Fbk->Opn]: Seg Fault in openssl_x509_parse
ID: 47828 Updated by: paj...@php.net Reported By: reinke at securityspace dot com -Status: Feedback +Status: Open Bug Type: OpenSSL related Operating System: Linux (Debian Lenny) PHP Version: 5.2.9 Assigned To: pajoye 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-29 21:51:04] paj...@php.net Thanks for testing all these distributions but it is not what I was asking. Please use PHP.net's sources, available in our downloads page, snapshots via cvs. See my next comment for the snapshot links. [2009-03-29 21:50:43] reinke at securityspace dot com Updated OS' impacted. [2009-03-29 21:48:55] reinke at securityspace dot com Further testing has confirmed this is reproducible on a variety of Linux distributions. Some of these have been tested with virgin (installed from ISOs, but no updates applied) configurations, some with fully up to date (all updates applied). Confirmed as reproducible: Distro PHP version - Debian 5.0 5.2.6-1+lenny2 Ubuntu 8.10 PHP 5.2.6-2ubuntu4.1 with Suhosin-Patch 0.9.6.2 Fedora Core 10 PHP 5.2.6 Slackware 12.1 PHP 5.2.5 Gentoo PHP 5.2.6-r7 (old version), 5.2.8-r2 (up to date) Debian 5.0 systems are fully up to date. Ubuntu 8.10 tested 2 setups, both seg faulted. - Setup 1: Latest PHP, ISO version of OpenSSL - Setup 2: Fully updated system Fedora Core 10 - tested both on virgin setup as well as fully up to date systems. Both setups segfaulted. Slackware - only virgin setup tested. Gentoo - 5.2.6-r7 - known out of date. 5.2.8-r2 involved a sync and rebuild of openssl and php along with a few other packages. Both seg faulted. On vulnerable systems, running "openssl x509 -inform PEM -in badcert.pem -text" where the signed pub key provided earlier is in "badcert.pem" (with \n markers appropriately changed to newline) spits out all information in the cert without any apparent problems. The Unbutu 8.10 gdb backtrace is typical of of the systems we tested (we stopped checking backtraces after Deb, Ubuntu, FC10 all produced the same thing) # gdb php (gdb) r core2.php Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb78088e0 (LWP 4011)] 0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0x in ?? () #2 0x082dea85 in add_next_index_stringl () #3 0x0809df90 in ?? () #4 0x0809e23a in zif_openssl_x509_parse () #5 0x08313f23 in ?? () #6 0x082ff3bb in execute () If you really think our SSL packages were out of date, we can provide that info. But we're pretty sure that in situations where we said we're fully up to date, that we were. We're aware we could install PHP from sources directly from php.net, but for maintenance reasons _really_ want to use the distro's packages. ALL of the above testing was using the distro's prepackaged software. We could NOT reproduce this on: CentOS 5.1 (php 5.1.6-20.el5_2.1) RedHat 5.2 (php 5.1.6-20.el5) [2009-03-29 17:20:16] paj...@php.net Can't reproduce on Ubuntu 8.10, windows or latest debian (using PHP sources). I would suggest to first see if you have the latest openssl (openssl debian's package contains the latest fixes) install. [2009-03-29 16:09:50] paj...@php.net Please try using our official releases, not the patched PHP from Debian. I will also test your csr later this week. 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=47828&edit=1
#47828 [Opn->Fbk]: Seg Fault in openssl_x509_parse
ID: 47828 Updated by: paj...@php.net Reported By: reinke at securityspace dot com -Status: Open +Status: Feedback Bug Type: OpenSSL related -Operating System: Linux (Multiple Distributions) +Operating System: Linux (Debian Lenny) PHP Version: 5.2.9 Assigned To: pajoye New Comment: Thanks for testing all these distributions but it is not what I was asking. Please use PHP.net's sources, available in our downloads page, snapshots via cvs. See my next comment for the snapshot links. Previous Comments: [2009-03-29 21:50:43] reinke at securityspace dot com Updated OS' impacted. [2009-03-29 21:48:55] reinke at securityspace dot com Further testing has confirmed this is reproducible on a variety of Linux distributions. Some of these have been tested with virgin (installed from ISOs, but no updates applied) configurations, some with fully up to date (all updates applied). Confirmed as reproducible: Distro PHP version - Debian 5.0 5.2.6-1+lenny2 Ubuntu 8.10 PHP 5.2.6-2ubuntu4.1 with Suhosin-Patch 0.9.6.2 Fedora Core 10 PHP 5.2.6 Slackware 12.1 PHP 5.2.5 Gentoo PHP 5.2.6-r7 (old version), 5.2.8-r2 (up to date) Debian 5.0 systems are fully up to date. Ubuntu 8.10 tested 2 setups, both seg faulted. - Setup 1: Latest PHP, ISO version of OpenSSL - Setup 2: Fully updated system Fedora Core 10 - tested both on virgin setup as well as fully up to date systems. Both setups segfaulted. Slackware - only virgin setup tested. Gentoo - 5.2.6-r7 - known out of date. 5.2.8-r2 involved a sync and rebuild of openssl and php along with a few other packages. Both seg faulted. On vulnerable systems, running "openssl x509 -inform PEM -in badcert.pem -text" where the signed pub key provided earlier is in "badcert.pem" (with \n markers appropriately changed to newline) spits out all information in the cert without any apparent problems. The Unbutu 8.10 gdb backtrace is typical of of the systems we tested (we stopped checking backtraces after Deb, Ubuntu, FC10 all produced the same thing) # gdb php (gdb) r core2.php Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb78088e0 (LWP 4011)] 0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0x in ?? () #2 0x082dea85 in add_next_index_stringl () #3 0x0809df90 in ?? () #4 0x0809e23a in zif_openssl_x509_parse () #5 0x08313f23 in ?? () #6 0x082ff3bb in execute () If you really think our SSL packages were out of date, we can provide that info. But we're pretty sure that in situations where we said we're fully up to date, that we were. We're aware we could install PHP from sources directly from php.net, but for maintenance reasons _really_ want to use the distro's packages. ALL of the above testing was using the distro's prepackaged software. We could NOT reproduce this on: CentOS 5.1 (php 5.1.6-20.el5_2.1) RedHat 5.2 (php 5.1.6-20.el5) [2009-03-29 17:20:16] paj...@php.net Can't reproduce on Ubuntu 8.10, windows or latest debian (using PHP sources). I would suggest to first see if you have the latest openssl (openssl debian's package contains the latest fixes) install. [2009-03-29 16:09:50] paj...@php.net Please try using our official releases, not the patched PHP from Debian. I will also test your csr later this week. [2009-03-29 16:02:30] reinke at securityspace dot com Description: A user calling openssl_x509_parse is able to induce a segfault by passing in specific data. In this case, the data is a certificate found on a public SSL site. Command line version of PHP is used in latest Debian (Lenny), php -v reports: (Contrary to your form - I'm guessing Lenny is up to 5.2.9 with the patch line as shown below) PHP 5.2.6-1+lenny2 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 26 2009 22:41:04) PHP script that reproduces the problem is included below. This certificate is one of more than half a million. Only this certificate caused the coredump. Older (_much_ older - PHP 4.4.1) version of PHP did not exhibit this problem. In all fairness, it's not clear to me at this point that the problem is in PHP - it's looking highly possible to be in the underlying libraries. Reproduce code: --- Expected result: Not see a segmentation fault. Actual result: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb77946d0 (LWP 1
#47828 [Opn]: Seg Fault in openssl_x509_parse
ID: 47828 User updated by: reinke at securityspace dot com Reported By: reinke at securityspace dot com Status: Open Bug Type: OpenSSL related -Operating System: Linux (Debian Lenny) +Operating System: Linux (Multiple Distributions) PHP Version: 5.2.9 Assigned To: pajoye New Comment: Updated OS' impacted. Previous Comments: [2009-03-29 21:48:55] reinke at securityspace dot com Further testing has confirmed this is reproducible on a variety of Linux distributions. Some of these have been tested with virgin (installed from ISOs, but no updates applied) configurations, some with fully up to date (all updates applied). Confirmed as reproducible: Distro PHP version - Debian 5.0 5.2.6-1+lenny2 Ubuntu 8.10 PHP 5.2.6-2ubuntu4.1 with Suhosin-Patch 0.9.6.2 Fedora Core 10 PHP 5.2.6 Slackware 12.1 PHP 5.2.5 Gentoo PHP 5.2.6-r7 (old version), 5.2.8-r2 (up to date) Debian 5.0 systems are fully up to date. Ubuntu 8.10 tested 2 setups, both seg faulted. - Setup 1: Latest PHP, ISO version of OpenSSL - Setup 2: Fully updated system Fedora Core 10 - tested both on virgin setup as well as fully up to date systems. Both setups segfaulted. Slackware - only virgin setup tested. Gentoo - 5.2.6-r7 - known out of date. 5.2.8-r2 involved a sync and rebuild of openssl and php along with a few other packages. Both seg faulted. On vulnerable systems, running "openssl x509 -inform PEM -in badcert.pem -text" where the signed pub key provided earlier is in "badcert.pem" (with \n markers appropriately changed to newline) spits out all information in the cert without any apparent problems. The Unbutu 8.10 gdb backtrace is typical of of the systems we tested (we stopped checking backtraces after Deb, Ubuntu, FC10 all produced the same thing) # gdb php (gdb) r core2.php Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb78088e0 (LWP 4011)] 0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0x in ?? () #2 0x082dea85 in add_next_index_stringl () #3 0x0809df90 in ?? () #4 0x0809e23a in zif_openssl_x509_parse () #5 0x08313f23 in ?? () #6 0x082ff3bb in execute () If you really think our SSL packages were out of date, we can provide that info. But we're pretty sure that in situations where we said we're fully up to date, that we were. We're aware we could install PHP from sources directly from php.net, but for maintenance reasons _really_ want to use the distro's packages. ALL of the above testing was using the distro's prepackaged software. We could NOT reproduce this on: CentOS 5.1 (php 5.1.6-20.el5_2.1) RedHat 5.2 (php 5.1.6-20.el5) [2009-03-29 17:20:16] paj...@php.net Can't reproduce on Ubuntu 8.10, windows or latest debian (using PHP sources). I would suggest to first see if you have the latest openssl (openssl debian's package contains the latest fixes) install. [2009-03-29 16:09:50] paj...@php.net Please try using our official releases, not the patched PHP from Debian. I will also test your csr later this week. [2009-03-29 16:02:30] reinke at securityspace dot com Description: A user calling openssl_x509_parse is able to induce a segfault by passing in specific data. In this case, the data is a certificate found on a public SSL site. Command line version of PHP is used in latest Debian (Lenny), php -v reports: (Contrary to your form - I'm guessing Lenny is up to 5.2.9 with the patch line as shown below) PHP 5.2.6-1+lenny2 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 26 2009 22:41:04) PHP script that reproduces the problem is included below. This certificate is one of more than half a million. Only this certificate caused the coredump. Older (_much_ older - PHP 4.4.1) version of PHP did not exhibit this problem. In all fairness, it's not clear to me at this point that the problem is in PHP - it's looking highly possible to be in the underlying libraries. Reproduce code: --- Expected result: Not see a segmentation fault. Actual result: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb77946d0 (LWP 10516)] 0xb7985c1c in memcpy () from /lib/i686/cmov/libc.so.6 (gdb) bt #0 0xb7985c1c in memcpy () from /lib/i686/cmov/libc.so.6 #1 0x082b7571 in _estrndup () #2 0x082d8245 in add_next_index_stringl () #3 0x0809d6d0 in ?? () #4 0x08fea7c0 in ?? () #5 0xb7f332e0 in ?? () from /lib/ld-linux.so.2 #6 0xb77bab48 in ?? () #7 0x0001 in ?? (
#47828 [Fbk->Opn]: Seg Fault in openssl_x509_parse
ID: 47828 User updated by: reinke at securityspace dot com Reported By: reinke at securityspace dot com -Status: Feedback +Status: Open Bug Type: OpenSSL related Operating System: Linux (Debian Lenny) PHP Version: 5.2.9 Assigned To: pajoye New Comment: Further testing has confirmed this is reproducible on a variety of Linux distributions. Some of these have been tested with virgin (installed from ISOs, but no updates applied) configurations, some with fully up to date (all updates applied). Confirmed as reproducible: Distro PHP version - Debian 5.0 5.2.6-1+lenny2 Ubuntu 8.10 PHP 5.2.6-2ubuntu4.1 with Suhosin-Patch 0.9.6.2 Fedora Core 10 PHP 5.2.6 Slackware 12.1 PHP 5.2.5 Gentoo PHP 5.2.6-r7 (old version), 5.2.8-r2 (up to date) Debian 5.0 systems are fully up to date. Ubuntu 8.10 tested 2 setups, both seg faulted. - Setup 1: Latest PHP, ISO version of OpenSSL - Setup 2: Fully updated system Fedora Core 10 - tested both on virgin setup as well as fully up to date systems. Both setups segfaulted. Slackware - only virgin setup tested. Gentoo - 5.2.6-r7 - known out of date. 5.2.8-r2 involved a sync and rebuild of openssl and php along with a few other packages. Both seg faulted. On vulnerable systems, running "openssl x509 -inform PEM -in badcert.pem -text" where the signed pub key provided earlier is in "badcert.pem" (with \n markers appropriately changed to newline) spits out all information in the cert without any apparent problems. The Unbutu 8.10 gdb backtrace is typical of of the systems we tested (we stopped checking backtraces after Deb, Ubuntu, FC10 all produced the same thing) # gdb php (gdb) r core2.php Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb78088e0 (LWP 4011)] 0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0x in ?? () #2 0x082dea85 in add_next_index_stringl () #3 0x0809df90 in ?? () #4 0x0809e23a in zif_openssl_x509_parse () #5 0x08313f23 in ?? () #6 0x082ff3bb in execute () If you really think our SSL packages were out of date, we can provide that info. But we're pretty sure that in situations where we said we're fully up to date, that we were. We're aware we could install PHP from sources directly from php.net, but for maintenance reasons _really_ want to use the distro's packages. ALL of the above testing was using the distro's prepackaged software. We could NOT reproduce this on: CentOS 5.1 (php 5.1.6-20.el5_2.1) RedHat 5.2 (php 5.1.6-20.el5) Previous Comments: [2009-03-29 17:20:16] paj...@php.net Can't reproduce on Ubuntu 8.10, windows or latest debian (using PHP sources). I would suggest to first see if you have the latest openssl (openssl debian's package contains the latest fixes) install. [2009-03-29 16:09:50] paj...@php.net Please try using our official releases, not the patched PHP from Debian. I will also test your csr later this week. [2009-03-29 16:02:30] reinke at securityspace dot com Description: A user calling openssl_x509_parse is able to induce a segfault by passing in specific data. In this case, the data is a certificate found on a public SSL site. Command line version of PHP is used in latest Debian (Lenny), php -v reports: (Contrary to your form - I'm guessing Lenny is up to 5.2.9 with the patch line as shown below) PHP 5.2.6-1+lenny2 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 26 2009 22:41:04) PHP script that reproduces the problem is included below. This certificate is one of more than half a million. Only this certificate caused the coredump. Older (_much_ older - PHP 4.4.1) version of PHP did not exhibit this problem. In all fairness, it's not clear to me at this point that the problem is in PHP - it's looking highly possible to be in the underlying libraries. Reproduce code: --- Expected result: Not see a segmentation fault. Actual result: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb77946d0 (LWP 10516)] 0xb7985c1c in memcpy () from /lib/i686/cmov/libc.so.6 (gdb) bt #0 0xb7985c1c in memcpy () from /lib/i686/cmov/libc.so.6 #1 0x082b7571 in _estrndup () #2 0x082d8245 in add_next_index_stringl () #3 0x0809d6d0 in ?? () #4 0x08fea7c0 in ?? () #5 0xb7f332e0 in ?? () from /lib/ld-linux.so.2 #6 0xb77bab48 in ?? () #7 0x0001 in ?? () #8 0x0001 in ?? () #9 0xbfc385c4 in ?? () #10 0x08fea7c0 in ?? () #11 0x083587c3 in ?? () #12 0x08fe93b4 in ?? () #13 0x0001 in ?? () #14 0xb78da3e8 in ?? () from
#47745 [Asn]: FILTER_VALIDATE_INT doesn't allow minimum integer
ID: 47745 Updated by: scott...@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 New Comment: Must have been sleep deprived when I looked at this last. Previous Comments: [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: --- http://bugs.php.net/?id=47745&edit=1
#47826 [Opn->Csd]: undefined symbol: sqlite3_enable_load_extension
ID: 47826 Updated by: scott...@php.net Reported By: oeriksson at mandriva dot com -Status: Open +Status: Closed Bug Type: SQLite related Operating System: Mandriva Linux PHP Version: 5.3.0RC1 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. Noticed the error after looking at the code again. Previous Comments: [2009-03-29 17:42:20] scott...@php.net What configure line did you use? [2009-03-29 10:05:34] oeriksson at mandriva dot com Description: On Mandriva Linux Cooker I get: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/extensions/sqlite3.so' - /usr/lib/php/extensions/sqlite3.so: undefined symbol: sqlite3_enable_load_extension in Unknown on line 0 We have sqlite3-3.6.11 I noticed that SQLITE_OMIT_LOAD_EXTENSION is unset in main/php_config.h and should in this case be set to 1. $ grep SQLITE_OMIT_LOAD_EXTENSION main/php_config.h /* #undef SQLITE_OMIT_LOAD_EXTENSION */ Reproduce code: --- Just running php-cli Expected result: It should work Actual result: -- PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/extensions/sqlite3.so' - /usr/lib/php/extensions/sqlite3.so: undefined symbol: sqlite3_enable_load_extension in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=47826&edit=1
#47833 [NEW]: xpath::query fails when huge xml file loaded
From: getmequick at gmail dot com
Operating system: Windows XP
PHP version: 5.2.9
PHP Bug Type: DOM XML related
Bug description: xpath::query fails when huge xml file loaded
Description:
I'm running latest PHP 5.2.9.1 on Win XP machine with apache 2.0 on it
I have 1GB free RAM (of 2GB)
here's the issue, I load huge xml file (8MB) that has namespace defined in
it and try query with xpath, it ends with timeout error
strangely, when I move namespace definition out, it works.
also, if I reduce filesize to say 1KB it also works (with namespace
defined)
summary:
- Doesn't work when xml has a namespace defined and filesize is huge (~8MB
tested)
- Works when filesize is tiny and has a namespace.
- Works when filesize is huge and no namespace defined.
Reproduce code:
---
test.xml
--
http://www.google.com/schemas/sitemap/0.84";>
..
..
..
test.php
--
documentElement && $dom->documentElement->namespaceURI)
{
$xpath->registerNamespace('ns', $dom->documentElement->namespaceURI);
$ns= 'ns:';
}
$locUrls = $xpath->query("//{$ns}loc");
var_dump($locUrls);
?>
Expected result:
Nodelist object.
Actual result:
--
PHP timeout error.
--
Edit bug report at http://bugs.php.net/?id=47833&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47833&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47833&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47833&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47833&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47833&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47833&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47833&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47833&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47833&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47833&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47833&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47833&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47833&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47833&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47833&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47833&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47833&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47833&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47833&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47833&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47833&r=mysqlcfg
#47832 [Com]: Garbled associative array indices
ID: 47832
Comment by: r dot borschel at gmx dot net
Reported By: r dot borschel at gmx dot net
Status: Open
Bug Type: PDO related
Operating System: OS X 10.5.6
PHP Version: 5.3CVS-2009-03-29 (snap)
New Comment:
The INSERT statement should of course read:
INSERT INTO `testdb`.`cms_users` (
`id` ,
`status` ,
`username` ,
`name`
) VALUES (NULL , 'developer', 'romanb', 'Roman');
Previous Comments:
[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=47832&edit=1
#47832 [NEW]: Garbled associative array indices
From: r dot borschel at gmx dot net
Operating system: OS X 10.5.6
PHP version: 5.3CVS-2009-03-29 (snap)
PHP Bug Type: PDO related
Bug description: Garbled associative array indices
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 bug report at http://bugs.php.net/?id=47832&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47832&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47832&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47832&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47832&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47832&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47832&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47832&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47832&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47832&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47832&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47832&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47832&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47832&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47832&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47832&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47832&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47832&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47832&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47832&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47832&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47832&r=mysqlcfg
#47831 [NEW]: Compile warning for strnlen() in main/spprintf.c (missing #define _GNU_SOURCE)
From: rainer dot jung at kippdata dot de Operating system: Linux PHP version: 5.2.9 PHP Bug Type: Compile Warning Bug description: Compile warning for strnlen() in main/spprintf.c (missing #define _GNU_SOURCE) 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.4&r2=1.25.2.2.2.10.2.5 and http://cvs.php.net/viewvc.cgi/php-src/main/spprintf.c?r1=1.53&r2=1.54&; and compare with http://cvs.php.net/viewvc.cgi/php-src/main/spprintf.c?r1=1.25.2.2.2.14&r2=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 * for xinetd. */ +#define _GNU_SOURCE #include "php.h" #include -- Edit bug report at http://bugs.php.net/?id=47831&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47831&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47831&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47831&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47831&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47831&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47831&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47831&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47831&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47831&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47831&r=support Expected behavior: http://bugs.php.net/fix.php?id=47831&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47831&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47831&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47831&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47831&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47831&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47831&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47831&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47831&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47831&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47831&r=mysqlcfg
#47830 [Opn->Bgs]: getcwd() called during shutdown function returns '/'.
ID: 47830
Updated by: scott...@php.net
Reported By: myselfasunder at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Ubuntu
PHP Version: 5.2.9
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
>From the register_shutdown_function manual page.
"Note: Working directory of the script can change inside the shutdown
function under some web servers, e.g. Apache. "
Previous Comments:
[2009-03-29 18:47:54] myselfasunder at gmail dot com
Description:
Running under Apache 2. Error does not occur under the CLI.
Registered a shutdown function (register_shutdown_function()), and
while the shutdown function is executing, getcwd() returns '/'.
Reproduce code:
---
function shuttingdown()
{
print(getcwd() . "");
}
register_shutdown_function('shuttingdown');
Expected result:
The absolute path-name of the current working directory.
Actual result:
--
'/' (always, apparently)
--
Edit this bug report at http://bugs.php.net/?id=47830&edit=1
#47830 [NEW]: getcwd() called during shutdown function returns '/'.
From: myselfasunder at gmail dot com
Operating system: Ubuntu
PHP version: 5.2.9
PHP Bug Type: Unknown/Other Function
Bug description: getcwd() called during shutdown function returns '/'.
Description:
Running under Apache 2. Error does not occur under the CLI.
Registered a shutdown function (register_shutdown_function()), and while
the shutdown function is executing, getcwd() returns '/'.
Reproduce code:
---
function shuttingdown()
{
print(getcwd() . "");
}
register_shutdown_function('shuttingdown');
Expected result:
The absolute path-name of the current working directory.
Actual result:
--
'/' (always, apparently)
--
Edit bug report at http://bugs.php.net/?id=47830&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47830&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47830&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47830&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47830&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47830&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47830&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47830&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47830&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47830&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47830&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47830&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47830&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47830&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47830&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47830&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47830&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47830&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47830&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47830&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47830&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47830&r=mysqlcfg
#47826 [Opn]: undefined symbol: sqlite3_enable_load_extension
ID: 47826 Updated by: scott...@php.net Reported By: oeriksson at mandriva dot com Status: Open Bug Type: SQLite related Operating System: Mandriva Linux PHP Version: 5.3.0RC1 New Comment: What configure line did you use? Previous Comments: [2009-03-29 10:05:34] oeriksson at mandriva dot com Description: On Mandriva Linux Cooker I get: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/extensions/sqlite3.so' - /usr/lib/php/extensions/sqlite3.so: undefined symbol: sqlite3_enable_load_extension in Unknown on line 0 We have sqlite3-3.6.11 I noticed that SQLITE_OMIT_LOAD_EXTENSION is unset in main/php_config.h and should in this case be set to 1. $ grep SQLITE_OMIT_LOAD_EXTENSION main/php_config.h /* #undef SQLITE_OMIT_LOAD_EXTENSION */ Reproduce code: --- Just running php-cli Expected result: It should work Actual result: -- PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/extensions/sqlite3.so' - /usr/lib/php/extensions/sqlite3.so: undefined symbol: sqlite3_enable_load_extension in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=47826&edit=1
#47828 [Fbk]: Seg Fault in openssl_x509_parse
ID: 47828 Updated by: paj...@php.net Reported By: reinke at securityspace dot com Status: Feedback -Bug Type: Reproducible crash +Bug Type: OpenSSL related Operating System: Linux (Debian Lenny) PHP Version: 5.2.9 Assigned To: pajoye New Comment: Can't reproduce on Ubuntu 8.10, windows or latest debian (using PHP sources). I would suggest to first see if you have the latest openssl (openssl debian's package contains the latest fixes) install. Previous Comments: [2009-03-29 16:09:50] paj...@php.net Please try using our official releases, not the patched PHP from Debian. I will also test your csr later this week. [2009-03-29 16:02:30] reinke at securityspace dot com Description: A user calling openssl_x509_parse is able to induce a segfault by passing in specific data. In this case, the data is a certificate found on a public SSL site. Command line version of PHP is used in latest Debian (Lenny), php -v reports: (Contrary to your form - I'm guessing Lenny is up to 5.2.9 with the patch line as shown below) PHP 5.2.6-1+lenny2 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 26 2009 22:41:04) PHP script that reproduces the problem is included below. This certificate is one of more than half a million. Only this certificate caused the coredump. Older (_much_ older - PHP 4.4.1) version of PHP did not exhibit this problem. In all fairness, it's not clear to me at this point that the problem is in PHP - it's looking highly possible to be in the underlying libraries. Reproduce code: --- Expected result: Not see a segmentation fault. Actual result: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb77946d0 (LWP 10516)] 0xb7985c1c in memcpy () from /lib/i686/cmov/libc.so.6 (gdb) bt #0 0xb7985c1c in memcpy () from /lib/i686/cmov/libc.so.6 #1 0x082b7571 in _estrndup () #2 0x082d8245 in add_next_index_stringl () #3 0x0809d6d0 in ?? () #4 0x08fea7c0 in ?? () #5 0xb7f332e0 in ?? () from /lib/ld-linux.so.2 #6 0xb77bab48 in ?? () #7 0x0001 in ?? () #8 0x0001 in ?? () #9 0xbfc385c4 in ?? () #10 0x08fea7c0 in ?? () #11 0x083587c3 in ?? () #12 0x08fe93b4 in ?? () #13 0x0001 in ?? () #14 0xb78da3e8 in ?? () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #15 0x0901e9a8 in ?? () #16 0x0901ee20 in ?? () #17 0x in ?? () #18 0x0001 in ?? () #19 0xbfc38758 in ?? () #20 0xb7f332e0 in ?? () from /lib/ld-linux.so.2 #21 0x0809d947 in zif_openssl_x509_parse () Backtrace stopped: frame did not save the PC -- Edit this bug report at http://bugs.php.net/?id=47828&edit=1
#47745 [Asn]: FILTER_VALIDATE_INT doesn't allow minimum integer
ID: 47745 Updated by: paj...@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 New Comment: 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 :) Previous Comments: [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: --- http://bugs.php.net/?id=47745&edit=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 New Comment: 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... Previous Comments: [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: --- http://bugs.php.net/?id=47745&edit=1
#47815 [Opn->Asn]: Compile time computation of hash value decrease hash lookup time.
ID: 47815
Updated by: il...@php.net
Reported By: basant dot kukreja at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: Performance problem
Operating System: Solaris 10
PHP Version: 5.2.9
-Assigned To:
+Assigned To: dmitry
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
--- a/php-5.2.9RC3/Zend/zend_object_handlers.c Tue Mar 17 11:27:02 2009
-0700
+++ b/php-5.2.9RC3/Zend/zend_object_handlers.c Fri Mar 27 10:18:13 2009
-0700
@@ -175,24 +175,11 @@
return 0;
}
-ZEND_API struct _zend_property_info
*zend_get_property_info(zend_class_entry *ce, zval *member, int si
#47829 [NEW]: Segmentation fault on startup with PDO Firebird compiled in
From: info at programmiernutte dot net
Operating system: Debian Etch x86_64
PHP version: 5.3.0RC1
PHP Bug Type: Reproducible crash
Bug description: Segmentation fault on startup with PDO Firebird compiled in
Description:
I am getting Segmentation fault on startup, no matter if SAPI apache 2 or
CLI. Same Version of PHP and same Firebird Version (2.1.1.) are running
flawlessly on my G4 Mac on Mac OS X 10.4.11, so maybe this is
64bit-related?
I used gdb to track this down to PDO Firebird Initialisation Startup:
(gdb) run
Starting program: /usr/src/php-5.3.0RC1/sapi/cli/php
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread 47013927445712 (LWP 16824)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47013927445712 (LWP 16824)]
zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
3210if (ce->type & ZEND_INTERNAL_CLASS) {
(gdb) where
#0 zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
#1 0x005190c2 in zm_startup_pdo_firebird (type=, module_number=)
at /usr/src/php-5.3.0RC1/ext/pdo_firebird/pdo_firebird.c:58
#2 0x0061cfbe in zend_startup_module_ex (module=0xcafb10) at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1593
#3 0x00625f05 in zend_hash_apply (ht=0xc62e80,
apply_func=0x61cec0 )
at /usr/src/php-5.3.0RC1/Zend/zend_hash.c:673
#4 0x0061d89a in zend_startup_modules () at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1642
#5 0x005c827f in php_module_startup (sf=,
additional_modules=0x0, num_additional_modules=0)
at /usr/src/php-5.3.0RC1/main/main.c:1952
#6 0x006a0e5d in php_cli_startup (sapi_module=0x0) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:370
#7 0x006a155f in main (argc=1, argv=0x7fff63c23928) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:742
--
Edit bug report at http://bugs.php.net/?id=47829&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47829&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47829&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47829&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47829&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47829&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47829&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47829&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47829&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47829&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47829&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47829&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47829&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47829&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47829&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47829&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47829&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47829&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47829&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47829&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47829&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47829&r=mysqlcfg
#47828 [Opn->Fbk]: Seg Fault in openssl_x509_parse
ID: 47828 Updated by: paj...@php.net Reported By: reinke at securityspace dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Linux (Debian Lenny) PHP Version: 5.2.9 -Assigned To: +Assigned To: pajoye New Comment: Please try using our official releases, not the patched PHP from Debian. I will also test your csr later this week. Previous Comments: [2009-03-29 16:02:30] reinke at securityspace dot com Description: A user calling openssl_x509_parse is able to induce a segfault by passing in specific data. In this case, the data is a certificate found on a public SSL site. Command line version of PHP is used in latest Debian (Lenny), php -v reports: (Contrary to your form - I'm guessing Lenny is up to 5.2.9 with the patch line as shown below) PHP 5.2.6-1+lenny2 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 26 2009 22:41:04) PHP script that reproduces the problem is included below. This certificate is one of more than half a million. Only this certificate caused the coredump. Older (_much_ older - PHP 4.4.1) version of PHP did not exhibit this problem. In all fairness, it's not clear to me at this point that the problem is in PHP - it's looking highly possible to be in the underlying libraries. Reproduce code: --- Expected result: Not see a segmentation fault. Actual result: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb77946d0 (LWP 10516)] 0xb7985c1c in memcpy () from /lib/i686/cmov/libc.so.6 (gdb) bt #0 0xb7985c1c in memcpy () from /lib/i686/cmov/libc.so.6 #1 0x082b7571 in _estrndup () #2 0x082d8245 in add_next_index_stringl () #3 0x0809d6d0 in ?? () #4 0x08fea7c0 in ?? () #5 0xb7f332e0 in ?? () from /lib/ld-linux.so.2 #6 0xb77bab48 in ?? () #7 0x0001 in ?? () #8 0x0001 in ?? () #9 0xbfc385c4 in ?? () #10 0x08fea7c0 in ?? () #11 0x083587c3 in ?? () #12 0x08fe93b4 in ?? () #13 0x0001 in ?? () #14 0xb78da3e8 in ?? () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #15 0x0901e9a8 in ?? () #16 0x0901ee20 in ?? () #17 0x in ?? () #18 0x0001 in ?? () #19 0xbfc38758 in ?? () #20 0xb7f332e0 in ?? () from /lib/ld-linux.so.2 #21 0x0809d947 in zif_openssl_x509_parse () Backtrace stopped: frame did not save the PC -- Edit this bug report at http://bugs.php.net/?id=47828&edit=1
#47828 [NEW]: Seg Fault in openssl_x509_parse
From: reinke at securityspace dot com Operating system: Linux (Debian Lenny) PHP version: 5.2.9 PHP Bug Type: Reproducible crash Bug description: Seg Fault in openssl_x509_parse Description: A user calling openssl_x509_parse is able to induce a segfault by passing in specific data. In this case, the data is a certificate found on a public SSL site. Command line version of PHP is used in latest Debian (Lenny), php -v reports: (Contrary to your form - I'm guessing Lenny is up to 5.2.9 with the patch line as shown below) PHP 5.2.6-1+lenny2 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 26 2009 22:41:04) PHP script that reproduces the problem is included below. This certificate is one of more than half a million. Only this certificate caused the coredump. Older (_much_ older - PHP 4.4.1) version of PHP did not exhibit this problem. In all fairness, it's not clear to me at this point that the problem is in PHP - it's looking highly possible to be in the underlying libraries. Reproduce code: --- Expected result: Not see a segmentation fault. Actual result: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb77946d0 (LWP 10516)] 0xb7985c1c in memcpy () from /lib/i686/cmov/libc.so.6 (gdb) bt #0 0xb7985c1c in memcpy () from /lib/i686/cmov/libc.so.6 #1 0x082b7571 in _estrndup () #2 0x082d8245 in add_next_index_stringl () #3 0x0809d6d0 in ?? () #4 0x08fea7c0 in ?? () #5 0xb7f332e0 in ?? () from /lib/ld-linux.so.2 #6 0xb77bab48 in ?? () #7 0x0001 in ?? () #8 0x0001 in ?? () #9 0xbfc385c4 in ?? () #10 0x08fea7c0 in ?? () #11 0x083587c3 in ?? () #12 0x08fe93b4 in ?? () #13 0x0001 in ?? () #14 0xb78da3e8 in ?? () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #15 0x0901e9a8 in ?? () #16 0x0901ee20 in ?? () #17 0x in ?? () #18 0x0001 in ?? () #19 0xbfc38758 in ?? () #20 0xb7f332e0 in ?? () from /lib/ld-linux.so.2 #21 0x0809d947 in zif_openssl_x509_parse () Backtrace stopped: frame did not save the PC -- Edit bug report at http://bugs.php.net/?id=47828&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47828&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47828&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47828&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47828&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47828&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47828&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47828&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47828&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47828&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47828&r=support Expected behavior: http://bugs.php.net/fix.php?id=47828&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47828&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47828&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47828&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47828&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47828&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47828&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47828&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47828&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47828&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47828&r=mysqlcfg
#47827 [NEW]: Rename fails to move non-empty directories around on same remote WinXP fullcont
From: dianerrr at hotmail dot com Operating system: Linux + WinXp PHP version: 5.2.9 PHP Bug Type: Directory function related Bug description: Rename fails to move non-empty directories around on same remote WinXP fullcont Description: I've noticed the following (cornercase of usage), but still faulty behavior of rename: I mount a WindowsXP full control share This share contains directories and all directories contain files and directories (otherwise reproduction will fail) I created a piece of code that mounts a samba share and then I try to move the non-empty directory "EXAMPLE" to "EXAMPLE_OLD" so to have some form of rotation. However the rename-function fails right after it created a directory named "EXAMPLE_OLD". So now I have two directories, the original (still non-empty) and the 'copy' (i didn't want) without any files. It seems like the internals of rename are incompatible with WindowsXP + Samba share. BTW: I tried the same items in normal bash and that worked flawlessly. I ran the PHP script as root on my bash and the WinXP share is fullcontrol to everyone. Reproduce code: --- --- >From manual page: function.rename --- #!/bin/php url ." ". TEMP_MOUNT_TARGET ); $files = scandir( $inboxDir ); for( $i=0; $i Expected result: Renamed directory on WinXP-share Actual result: -- Warning and a empty copy of directory on WinXP share -- Edit bug report at http://bugs.php.net/?id=47827&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47827&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47827&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47827&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47827&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47827&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47827&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47827&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47827&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47827&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47827&r=support Expected behavior: http://bugs.php.net/fix.php?id=47827&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47827&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47827&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47827&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47827&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47827&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47827&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47827&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47827&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47827&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47827&r=mysqlcfg
#47766 [Opn->Fbk]: php-cgi.exe crashes
ID: 47766 Updated by: paj...@php.net Reported By: ipseno at yahoo dot com -Status: Open +Status: Feedback Bug Type: CGI related Operating System: Win XP SP3 PHP Version: 5.3CVS-2009-03-24 (snap) -Assigned To: +Assigned To: pajoye New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2009-03-29 11:45:19] ipseno at yahoo dot com I have just used lattest windows snapshot of VC9 x86 Non Thread Safe. Bug is still present, so crash still occurs. [2009-03-29 06:05:39] scott...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Pretty sure this was fixed on Wednesday / Thursday. [2009-03-29 03:42:47] ipseno at yahoo dot com Thread 0 - System ID 7056Entry point php_cgi+61ea Create time 29.3.2009 1:37:02 Time spent in user mode 0 Days 0:0:0.0 Time spent in kernel mode 0 Days 0:0:0.93 FunctionArg 1 Arg 2 Arg 3 Source php5!lex_scan+2c06 00c0c8e40001002f php5!zend_register_auto_global+7f PHP5!LEX_SCAN+2C06WARNING - DebugDiag was not able to locate debug symbols for php5.dll, so the information below may be incomplete. In php-cgi__PID__6828__Date__03_29_2009__Time_01_37_08AM__796__Second_Chance_Exception_C005.dmp the assembly instruction at php5!lex_scan+2c06 in D:\Program Files\php\php5.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x02461000 on thread 0Module Information Image Name: D:\Program Files\php\php5.dll Symbol Type: Export Base address: 0x1000Time Stamp: Tue Mar 24 15:58:10 2009 Checksum: 0x0055c816Comments: COM DLL:False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter:False File Version: 5.3.0RC2-dev Managed DLL:False Internal Name:PHP Script Interpreter VB DLL: False Legal Copyright: Copyright © 1997-2008 The PHP Group Loaded Image Name: php5.dll Legal Trademarks: PHP Mapped Image Name:Original filename:php5.dll Module name:php5 Private Build: Single Threaded:False Product Name: PHP Module Size:5,45 MBytes Product Version: 5.3.0RC2-dev Symbol File Name: php5.dll Special Build:& [2009-03-25 22:16:36] ipseno at yahoo dot com Thread 0 - System ID 1888Entry point php_cgi+61ea Create time 25.3.2009 23:08:05 Time spent in user mode 0 Days 0:0:0.46 Time spent in kernel mode 0 Days 0:0:0.78 FunctionArg 1 Arg 2 Arg 3 Source php5!lex_scan+2c06 00c0c8e40001002f php5!zend_register_auto_global+7f PHP5!LEX_SCAN+2C06WARNING - DebugDiag was not able to locate debug symbols for php5.dll, so the information below may be incomplete. In php-cgi__PID__2540__Date__03_25_2009__Time_11_08_11PM__531__Second_Chance_Exception_C005.dmp the assembly instruction at php5!lex_scan+2c06 in D:\Program Files\php\php5.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x02461000 on thread 0Module Information Image Name: D:\Program Files\php\php5.dll Symbol Type: Export Base address: 0x1000Time Stamp: Tue Mar 24 15:58:10 2009 Checksum: 0x0055c816Comments: COM DLL:False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter:False File Version: 5.3.0RC2-dev Managed DLL:False Internal Name:PHP Script Interpreter VB DLL: False Legal Copyright: Copyright © 1997-2008 The PHP Group Loaded Image Name: php5.dll Legal Trademarks: PHP Mapped Image Name:Original filename:php5.dll Module name:
#47817 [Opn]: PHP hangs when running proc_open()
ID: 47817
User updated by: steven dot abarnett at gmail dot com
Reported By: steven dot abarnett at gmail dot com
Status: Open
Bug Type: Reproducible crash
Operating System: Windows XP
PHP Version: 5.2.9
New Comment:
I have found a fix for now, although I would like to know if better
options exist. The fault seems to lie in Windows. Both XP and Vista
refuse to allow file descriptors over 2. When I changed the code like so
it worked just fine:
$descriptors = array(
0 => array("pipe", "r"), // STDIN. Used to feed input
1 => array("pipe", "r"), // STDOUT. We are writing to it,
though
2 => array("pipe", "w"), // STDERR. Used to read errors
);
// Build the command line and start the process
$cmd = '"C:/program files/gnu/gnupg/gpg.exe" --batch
--no-verbose --passphrase-fd 1 --output decrypted.zip --decrypt
encrypted.zip.gpg';
$gpg = proc_open( $cmd, $descriptors, $pipes);
if(is_resource($gpg)) {
// Push passphrase to custom pipe
fwrite($pipes[1], $passphrase);
fclose($pipes[1]);
proc_close($gpg);
}
Is there a solution to be able to create more pipes in Windows? It's
very inconvenient having to write to STDOUT just to make my program work
properly, as it prevents me from reading any output thrown out by the
code (other than errors)
Previous Comments:
[2009-03-28 02:48:21] steven dot abarnett at gmail dot com
Description:
Unfortunately as far as I can tell, I am the only person having this
problem- which leads me to wonder if it's an issue with my PHP
configuration. Although I keep using default configuration, so I am at a
loss. I have tried installing PHP and Apache, I have tried in xampp, and
I have tried in WAMP. Every time after running the proc_open() command
the PHP script will wait for the process to close before reading the
next line- making reading or writing to any pipes impossible.
$fileDesc = array(
0 => array("pipe", "r"), // STDIN
1 => array("pipe", "w"), // STDOUT
2 => array("pipe", "w") // STDERR
);
die("Got this far");
$handle = proc_open("C:/wherever/program.exe", $fileDesc, $pipes);
fwrite($pipes[0], "input");
fclose($pipes[0]);
proc_close($handle);
Displays "Got this far" and dies, as expected. However:
$fileDesc = array(
0 => array("pipe", "r"), // STDIN
1 => array("pipe", "w"), // STDOUT
2 => array("pipe", "w") // STDERR
);
$handle = proc_open("C:/wherever/program.exe", $fileDesc, $pipes);
die("Got this far");
fwrite($pipes[0], "input");
fclose($pipes[0]);
proc_close($handle);
Will simply hang and seem to cease all function. The moment that I
close program.exe through task manager the script continues as if
nothing were wrong, dying with the output "Got this far". The input is
never passed to the program, although no errors are raised when I hit
the proc_close() line.
Reproduce code:
---
$descriptors = array(
0 => array("pipe", "r"), // STDIN. Used to feed input
1 => array("pipe", "w"), // STDOUT. Used to read output
2 => array("pipe", "w"), // STDERR. Used to read errors
3 => array("pipe", "r") // We can feed the passphrase here
);
// Build the command line and start the process
$cmd = '"C:/program files/gnu/gnupg/gpg.exe" --batch
--no-verbose --passphrase-fd 3 --output decrypted.zip --decrypt
encrypted.zip.gpg';
$gpg = proc_open( $cmd, $descriptors, $pipes);
if(is_resource($gpg)) {
// Push passphrase to custom pipe
fwrite($pipes[3], $passphrase);
fclose($pipes[3]);
proc_close($gpg);
}
Expected result:
Expected to find decrypted.zip in the same directory as the PHP script
(a decrypted version of encrypted.zip.gpg, which is located in the same
directory as the PHP script)
Actual result:
--
When localhost/test.php was run the webpage continued to load
indefinitely. I waited as long as 20 minutes. The PHP.ini file should
stop execution after 30 seconds. When gpg.exe was killed with task
manager the page loaded but the .zip file was never created.
--
Edit this bug report at http://bugs.php.net/?id=47817&edit=1
#47766 [Fbk->Opn]: php-cgi.exe crashes
ID: 47766 User updated by: ipseno at yahoo dot com Reported By: ipseno at yahoo dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Win XP SP3 PHP Version: 5.3CVS-2009-03-24 (snap) New Comment: I have just used lattest windows snapshot of VC9 x86 Non Thread Safe. Bug is still present, so crash still occurs. Previous Comments: [2009-03-29 06:05:39] scott...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Pretty sure this was fixed on Wednesday / Thursday. [2009-03-29 03:42:47] ipseno at yahoo dot com Thread 0 - System ID 7056Entry point php_cgi+61ea Create time 29.3.2009 1:37:02 Time spent in user mode 0 Days 0:0:0.0 Time spent in kernel mode 0 Days 0:0:0.93 FunctionArg 1 Arg 2 Arg 3 Source php5!lex_scan+2c06 00c0c8e40001002f php5!zend_register_auto_global+7f PHP5!LEX_SCAN+2C06WARNING - DebugDiag was not able to locate debug symbols for php5.dll, so the information below may be incomplete. In php-cgi__PID__6828__Date__03_29_2009__Time_01_37_08AM__796__Second_Chance_Exception_C005.dmp the assembly instruction at php5!lex_scan+2c06 in D:\Program Files\php\php5.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x02461000 on thread 0Module Information Image Name: D:\Program Files\php\php5.dll Symbol Type: Export Base address: 0x1000Time Stamp: Tue Mar 24 15:58:10 2009 Checksum: 0x0055c816Comments: COM DLL:False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter:False File Version: 5.3.0RC2-dev Managed DLL:False Internal Name:PHP Script Interpreter VB DLL: False Legal Copyright: Copyright © 1997-2008 The PHP Group Loaded Image Name: php5.dll Legal Trademarks: PHP Mapped Image Name:Original filename:php5.dll Module name:php5 Private Build: Single Threaded:False Product Name: PHP Module Size:5,45 MBytes Product Version: 5.3.0RC2-dev Symbol File Name: php5.dll Special Build:& [2009-03-25 22:16:36] ipseno at yahoo dot com Thread 0 - System ID 1888Entry point php_cgi+61ea Create time 25.3.2009 23:08:05 Time spent in user mode 0 Days 0:0:0.46 Time spent in kernel mode 0 Days 0:0:0.78 FunctionArg 1 Arg 2 Arg 3 Source php5!lex_scan+2c06 00c0c8e40001002f php5!zend_register_auto_global+7f PHP5!LEX_SCAN+2C06WARNING - DebugDiag was not able to locate debug symbols for php5.dll, so the information below may be incomplete. In php-cgi__PID__2540__Date__03_25_2009__Time_11_08_11PM__531__Second_Chance_Exception_C005.dmp the assembly instruction at php5!lex_scan+2c06 in D:\Program Files\php\php5.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x02461000 on thread 0Module Information Image Name: D:\Program Files\php\php5.dll Symbol Type: Export Base address: 0x1000Time Stamp: Tue Mar 24 15:58:10 2009 Checksum: 0x0055c816Comments: COM DLL:False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter:False File Version: 5.3.0RC2-dev Managed DLL:False Internal Name:PHP Script Interpreter VB DLL: False Legal Copyright: Copyright © 1997-2008 The PHP Group Loaded Image Name: php5.dll Legal Trademarks: PHP Mapped Image Name:Original filename:php5.dll Module name:php5 Private Build: Single Threaded:False Product Name: PHP Module Size:5,45 MBytes Product Version: 5.3.0RC2-dev Symbol File Name: php5.dll Special Build:& [2009-03-25 13:16:58] ipseno at yahoo dot com Ok, I will make a backtrace then and post it here. But until I do it, this is last what I found out: Remember comment line: // From DB Well if I remove JUST one dot it becomes: // From DB... and NO crash occurs!!! If I ADD just one dot it becomes: // From DB. and NO crash occ
#47826 [NEW]: undefined symbol: sqlite3_enable_load_extension
From: oeriksson at mandriva dot com Operating system: Mandriva Linux PHP version: 5.3.0RC1 PHP Bug Type: SQLite related Bug description: undefined symbol: sqlite3_enable_load_extension Description: On Mandriva Linux Cooker I get: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/extensions/sqlite3.so' - /usr/lib/php/extensions/sqlite3.so: undefined symbol: sqlite3_enable_load_extension in Unknown on line 0 We have sqlite3-3.6.11 I noticed that SQLITE_OMIT_LOAD_EXTENSION is unset in main/php_config.h and should in this case be set to 1. $ grep SQLITE_OMIT_LOAD_EXTENSION main/php_config.h /* #undef SQLITE_OMIT_LOAD_EXTENSION */ Reproduce code: --- Just running php-cli Expected result: It should work Actual result: -- PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/extensions/sqlite3.so' - /usr/lib/php/extensions/sqlite3.so: undefined symbol: sqlite3_enable_load_extension in Unknown on line 0 -- Edit bug report at http://bugs.php.net/?id=47826&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47826&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47826&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47826&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47826&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47826&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47826&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47826&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47826&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47826&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47826&r=support Expected behavior: http://bugs.php.net/fix.php?id=47826&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47826&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47826&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47826&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47826&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47826&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47826&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47826&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47826&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47826&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47826&r=mysqlcfg
#47825 [NEW]: POST Data being ignored
From: tiposchi at tiscali dot it
Operating system: GNU/Linux
PHP version: 5.2.9
PHP Bug Type: CGI related
Bug description: POST Data being ignored
Description:
CGI protocol says that POST data must be passed to the script using
its standard input.
So what i have to do is something like (see the attached code).
Anyway, the php knows how long the input will be because it has an
environmental variable called content length that says it.
So php should wait to read the entire post data before going on.
Since i don't have any information about how the scheduler works, i
can't assure the father process to fill the pipe before the child is
scheduled.
But php ignores the data if the pipe isn't full already. So what i
did was filling the pipe BEFORE the fork, and doing this it works.
But there is another problem. With large POST data, the buffer is
filled and the OS puts my process on wait until the pipe is empty by
another process. But i didn't start the php yet because it wants all
the post data already present, so the webserver just hangs.
I think you should review the way php-cgi reads post data.
Thanks
Reproduce code:
---
p=pipe()
if (fork()==0) {
close(STDIN)
dup(p)
exec ("php")
} else {
write(p,str_post)
wait()
}
I HAVE MADE THE CODE SIMPLE. I KNOW THIS CAN'T WORK.
--
Edit bug report at http://bugs.php.net/?id=47825&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47825&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47825&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47825&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47825&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47825&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47825&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47825&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47825&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47825&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47825&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47825&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47825&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47825&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47825&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47825&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47825&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47825&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47825&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47825&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47825&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47825&r=mysqlcfg
