#40626 [NEW]: preg_match and koi8-r
From: themixa at gmail dot com Operating system: Linux(PHP-5.1.6), Freebsd(PHP-4) PHP version: 4.4.5 PHP Bug Type: PCRE related Bug description: preg_match and koi8-r Description: preg_match don't recognize some letters in KOI8-R. Reproduce code: --- Expected result: First and second preg_match must return 1 Actual result: -- Only second preg_match must return 1 -- Edit bug report at http://bugs.php.net/?id=40626&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40626&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40626&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40626&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40626&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40626&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40626&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40626&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40626&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40626&r=support Expected behavior:http://bugs.php.net/fix.php?id=40626&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40626&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40626&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40626&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40626&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40626&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40626&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40626&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40626&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40626&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40626&r=mysqlcfg
#40625 [NEW]: Indirect modification of overloaded property
From: [EMAIL PROTECTED] Operating system: XP SP2 PHP version: 5.2.1 PHP Bug Type: Class/Object related Bug description: Indirect modification of overloaded property Description: While using __get and __set im getting the following notice : "Notice: Indirect modification of overloaded property $var has no effect " It worked perfect in previous PHP versions. Reproduce code: --- class myclass { /* $this->_data = array(1) { ["abcd"] => array(2) { ["a"] => string(2) "cc" ["b"] => string(2) "dd" } } */ public function __get($name) { $result = null; if (isset($this->_data[$name])) { $result = $this->_data[$name]; } return (array)$this->_data[$name] ; } public function __set($value, $arg) { foreach($arg as $key=>$inhoud) { $this->_data[$value][$key] = $inhoud; } } } $myclass = new myclass(); $myclass->abcd['a'] = 'ee'; //does not work anymore $myclass->newNode['a'] = 'ee'; //does not work anymore Expected result: array(2) { ["abcd"] => array(2) { ["a"] => string(2) "ee" ["b"] => string(2) "dd" } ["newNode"] => string(2) "ee" } Actual result: -- Data does not change and outputs "Notice: Indirect modification of overloaded property $var has no effect " -- Edit bug report at http://bugs.php.net/?id=40625&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40625&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40625&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40625&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40625&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40625&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40625&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40625&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40625&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40625&r=support Expected behavior:http://bugs.php.net/fix.php?id=40625&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40625&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40625&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40625&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40625&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40625&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40625&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40625&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40625&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40625&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40625&r=mysqlcfg
#40624 [NEW]: pcrelib broken with php 4.4.5
From: test_junk at hotmail dot it Operating system: linux 2.4 i386 PHP version: 4.4.5 PHP Bug Type: PCRE related Bug description: pcrelib broken with php 4.4.5 Description: Recent update to php 4.4.5 broke PCRE regex support. The issue showed up upgrading to 4.4.5 installed as apache module (1.3.37 both on 2.4 and 2.6 kernels) and was resolved downgrading back to 4.4.4 I could trigger a segfault with several applications but I was not able to detect the chunk of php code responsible of it. Actual result: -- segfault... #0 match (eptr=0x0, ecode=0x0, offset_top=0, md=0x0, ims=0, eptrb=0x0, flags=0, rdepth=0) at /sources/php-4.4.5/ext/pcre/pcrelib/pcre_exec.c:517 Cannot access memory at address 0xbf7fff30 -- Edit bug report at http://bugs.php.net/?id=40624&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40624&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40624&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40624&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40624&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40624&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40624&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40624&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40624&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40624&r=support Expected behavior:http://bugs.php.net/fix.php?id=40624&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40624&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40624&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40624&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40624&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40624&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40624&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40624&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40624&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40624&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40624&r=mysqlcfg
#31050 [Com]: SOAP class will not parse WSDL file located on a secure HTTPS connection
ID: 31050 Comment by: youngad6 at gmail dot com Reported By: dylanwoster at mac dot com Status: No Feedback Bug Type: SOAP related Operating System: Mac OS X 10.3.6 PHP Version: 5.0.2 Assigned To: dmitry New Comment: Still a problem for PHP 5.2.1 running on OS X 10.4.8 ./configure --prefix=/apache2/php --enable-soap --enable-memory-limit --with-mysql=/usr/local/mysql --with-mysqli --with-zlib --with-xml --with-ldap=/usr --enable-cli --with-zlib-dir=/usr --enable-exif --enable-ftp --enable-mbstring --enable-mbregex --enable-dbx --enable-sockets --with-iodbc=/usr --with-curl=/usr --with-apxs2=/apache2/bin/apxs Previous Comments: [2006-05-31 10:13:14] ykin at vertriebsunion dot de I have the same problem here. It's all served by an actual xampp installation on win2k servers. The constructor is able to retrive the document per http and local file acess. The https case procuses after a timeout minute following warning and not shown followup errors: Warning: SoapClient::__construct(https://www.js.vertriebsunion.de/VuJournalService/Authentifizierung.asmx?WSDL) [function.--construct]: failed to open stream [2006-01-09 07:52:19] samirshah_082005 at yahoo dot com I am getting the same error when creating soap client of a web service with https. Did anyone find any solution? [2005-02-01 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-01-20 08:46:12] [EMAIL PROTECTED] I see no problems with latest CVS version on Linux, but I cannot test this on MacOS X. [2004-12-10 05:22:21] dylanwoster at mac dot com Description: The built in SOAP class for PHP5 will not parse a WSDL file located on a secure HTTPS connection. The same WSDL works fine on an identical build on a Linux machine and any HTTP connections work fine. Registered Streams: php, file, ftp, gopher, telnet, dict, ldap, http, https, ftps, compress.zlib './configure' '--with-mysql=/Library/MySQL' '--with- apxs2=/Library/Apache2/bin/apxs' '--prefix=/Library/ PHP5' '--with-mysqli=/Library/MySQL/bin/mysql_config' '--with-libxml-dir=/usr/include/libxml2' '--with-curl=/ usr/local' '--with-curlwrappers' '--with-mcrypt=/usr/ local' '--with-java=/usr/bin/java' '--with-openssl' '-- with-zlib' '--with-gd' '--with-jpeg-dir=/usr/local' '-- with-png-dir=/usr/local' '--enable-xslt' '--with-xslt- sablot' '--enable-soap' '--enable-sockets' '--enable- ftp' OpenSSL is version 0.9.7e Reproduce code: --- $client = new SoapClient( "https://arcweb.esri.com/services/v2/Authentication.wsdl"; ); echo( $client->getVersion( ) ); Expected result: On the Linux machine I get the version of the ESRI web services Actual result: -- Fatal error: Uncaught SoapFault exception: [WSDL] SOAP- ERROR: Parsing WSDL: Couldn't load from 'https:// arcweb.esri.com/services/v2/Authentication.wsdl' in / Users/dylanoster/Sites/www.maionline.com/site1/html/ soap.php:2 Stack trace: #0 {main} thrown in /Users/ dylanoster/Sites/www.maionline.com/site1/html/soap.php on line 2 -- Edit this bug report at http://bugs.php.net/?id=31050&edit=1
#40599 [Opn]: "make test" results in segmentation fault
ID: 40599 User updated by: lyle dot pritchett at dri dot edu Reported By: lyle dot pritchett at dri dot edu Status: Open Bug Type: Reproducible crash Operating System: Solaris 9, 10 PHP Version: 5CVS-2007-02-22 (snap) New Comment: An explanation of sorts: I've found that multiple sets of libraries and header files are clashing, specifically for pcre, openssl, libxml, and zlib (perhaps others). Despite specifying paths in "configure" for the latest versions in /opt, the configure script is not consistently applying that path as it checks for these packages and builds compiler options. Even worse, Solaris 10 now comes with a number of (outdated) versions of these as well, and portions of those are getting stirred into the mix. An example of the problem: specifying --with-openssl-dir=/opt results in configure not finding the necessary header files. I find that line 20825 of the configure script is replacing the supplied path with hardcoded references to /usr/local, et al. Manually adding /opt to that line solves the header location problem, but the compiler is still reporting large numbers of warnings about mismatched openssl variables. Another example: specifying --with-libxml2-dir=/opt is not sufficient to keep configure from finding /usr/bin/xml2-config and complaining that the version reported there is too old (big surprise). It should be picking up the xml2-config in /opt/bin. With a LOT of manual tweaking, I am able to get "make test" to complete without a sementation fault, but it is still reporting over 50 tests failing. At this point I am not comfortable installing this on a production server. Previous Comments: [2007-02-24 19:32:15] lyle dot pritchett at dri dot edu Don't know if this helps, but I added --disable-inline-optimization to the configure parms; "make test" now gets a little further: (gdb) run Starting program: /opt/src/php/php5.2-200702231530/sapi/cli/php run-tests.php warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 0074 warning: Lowest section in /lib/libdl.so.1 is .dynamic at 0094 = CWD : /opt/src/php/php5.2-200702231530 PHP : sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.2.2-dev ZEND_VERSION: 2.2.0 PHP_OS : SunOS - SunOS trapdoor 5.10 Generic_118833-24 sun4u INI actual : /opt/src/php/php5.2-200702231530 More .INIs : Extra dirs : = Program received signal SIGSEGV, Segmentation fault. 0x002570c8 in _zval_ptr_dtor (zval_ptr=0xffbfb750) at /opt/src/php/php5.2-200702231530/Zend/zend_execute_API.c:412 412 (*zval_ptr)->refcount--; (gdb) bt #0 0x002570c8 in _zval_ptr_dtor (zval_ptr=0xffbfb750) at /opt/src/php/php5.2-200702231530/Zend/zend_execute_API.c:412 #1 0x00259448 in zend_call_function (fci=0xffbfb7d8, fci_cache=Variable "fci_cache" is not available. ) at zend_execute.h:155 #2 0x0019e65c in array_user_compare (a=0x64af70, b=Variable "b" is not available. ) at /opt/src/php/php5.2-200702231530/ext/standard/array.c:592 #3 0x0027b854 in zend_qsort (base=Variable "base" is not available. ) at /opt/src/php/php5.2-200702231530/Zend/zend_qsort.c:83 #4 0x002719b8 in zend_hash_sort (ht=0x621318, sort_func=0x27b75c , compar=0x19e5a4 , renumber=1, tsrm_ls=0x3ed738) at /opt/src/php/php5.2-200702231530/Zend/zend_hash.c:1275 #5 0x00198170 in zif_usort (ht=Variable "ht" is not available. ) at /opt/src/php/php5.2-200702231530/ext/standard/array.c:660 #6 0x0028a2b8 in zend_do_fcall_common_helper_SPEC (execute_data=0xffbff170, tsrm_ls=0x3ed738) at zend_vm_execute.h:200 #7 0x00293804 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xffbff170, tsrm_ls=0x3ed738) at zend_vm_execute.h:1681 #8 0x00289ae8 in execute (op_array=0x3fc678, tsrm_ls=0x3ed738) at zend_vm_execute.h:92 #9 0x0026603c in zend_execute_scripts (type=8, tsrm_ls=0x3ed738, retval=Variable "retval" is not available. ) at /opt/src/php/php5.2-200702231530/Zend/zend.c:1135 ---Type to continue, or q to quit--- #10 0x0021805c in php_execute_script (primary_file=0xffbff8dc, tsrm_ls=0x3ed738) at /opt/src/php/php5.2-200702231530/main/main.c:1787 #11 0x00306494 in main (argc=2, argv=0xffbff9e4) at /opt/src/php/php5.2-200702231530/sapi/cli/php_cli.c:1127 (gdb) [2007-02-23 20:10:01] [EMAIL PROTECTED] Cannot reproduce. [2007-02-23 17:40:55] lyle dot pritchett at dri dot edu No joy. Rebuilt latest snap version (5.2-200702231530) with gcc 4.1.2. Still getting seg fault on self-test on both Solaris 9 and 10 SPARC servers. Also tried minimal config to eliminate possible effects of supplemental pack
#40622 [Opn->Bgs]: round function
ID: 40622 Updated by: [EMAIL PROTECTED] Reported By: bruno dot boccara at d2b dot com -Status: Open +Status: Bogus Bug Type: Math related Operating System: windows 2003 Apache 2 PHP Version: 4.4.5 New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. . Previous Comments: [2007-02-24 21:36:47] bruno dot boccara at d2b dot com Description: round function gives wrong value. Please do not send me to http://docs.sun.com/source/806-3568/ncg_goldberg.html, you have to admit that this is a bug ! if not, php CANNOT be use in production site with mathematical functions !!! Reproduce code: --- "; echo "direct = ".round (92.565, 2);echo ""; $valeur = 140.25*(1-(34/100)); echo "value = ".round($valeur,2);echo ""; settype($valeur,"string"); settype($valeur,"float"); echo "value2 = ".round($valeur,2); ?> Expected result: formula = 92.57 direct = 92.57 value = 92.57 value2 = 92.57 Actual result: -- formula = 92.56 // WRONG ! direct = 92.57 value = 92.56 // WRONG ! value2 = 92.57 -- Edit this bug report at http://bugs.php.net/?id=40622&edit=1
#40623 [NEW]: segfault with phpDenora v1.2.0
From: admin at jerrcs dot net Operating system: Linux/CentOS release 4.4 (Final) PHP version: 5.2.1 PHP Bug Type: Reproducible crash Bug description: segfault with phpDenora v1.2.0 Description: I'm running phpDenora v1.2.0 on my site. It segfaults whenever I access it. Errors like: [Sat Feb 24 16:20:00 2007] [notice] child pid 31360 exit signal Segmentation fault (11) php -v: PHP 5.2.1 (cli) (built: Feb 23 2007 06:11:52) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies No log handling enabled - turning on stderr logging Reproduce code: --- http://denora.nomadirc.net/?p=phpdenora (http://prdownloads.sourceforge.net/phpdenora/phpdenora-1.2.0.tar.gz?download) Expected result: Another page which works (phpdenora): http://www.ghostnetwork.org/phpdenora/ Actual result: -- http://jerrcs.net/backtrace.txt -- Edit bug report at http://bugs.php.net/?id=40623&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40623&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40623&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40623&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40623&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40623&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40623&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40623&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40623&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40623&r=support Expected behavior:http://bugs.php.net/fix.php?id=40623&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40623&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40623&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40623&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40623&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40623&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40623&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40623&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40623&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40623&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40623&r=mysqlcfg
#40622 [NEW]: round function
From: bruno dot boccara at d2b dot com Operating system: windows 2003 Apache 2 PHP version: 4.4.5 PHP Bug Type: Math related Bug description: round function Description: round function gives wrong value. Please do not send me to http://docs.sun.com/source/806-3568/ncg_goldberg.html, you have to admit that this is a bug ! if not, php CANNOT be use in production site with mathematical functions !!! Reproduce code: --- "; echo "direct = ".round (92.565, 2);echo ""; $valeur = 140.25*(1-(34/100)); echo "value = ".round($valeur,2);echo ""; settype($valeur,"string"); settype($valeur,"float"); echo "value2 = ".round($valeur,2); ?> Expected result: formula = 92.57 direct = 92.57 value = 92.57 value2 = 92.57 Actual result: -- formula = 92.56 // WRONG ! direct = 92.57 value = 92.56 // WRONG ! value2 = 92.57 -- Edit bug report at http://bugs.php.net/?id=40622&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40622&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40622&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40622&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40622&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40622&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40622&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40622&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40622&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40622&r=support Expected behavior:http://bugs.php.net/fix.php?id=40622&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40622&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40622&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40622&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40622&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40622&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40622&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40622&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40622&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40622&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40622&r=mysqlcfg
#40621 [Opn->Csd]: Crash when constructor called inappropriately (statically)
ID: 40621 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.2.1 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2007-02-24 20:57:29] [EMAIL PROTECTED] Description: PHP 5.2.x (tried 5.2.1, 5.2.0) crashes if a constructor is called statically from within the host class. Code explains this better. I realize I'm not SUPPOSED to do this, but I did it accidentally (I made a mistake). I expect the error message. It shouldn't, however, crash. Reproduce code: --- php -r 'class Foo { private function __construct() { } function get() { self::__construct(); } } Foo::get();' Expected result: E_FATAL Here's 5.1.6: Fatal error: Non-static method Foo::__construct() cannot be called statically in Command line code on line 1 In 5.2.0, this was downgraded to E_STRICT, which I suspect is why it crashes (E_FATAL would have bailed, E_STRICT tries to run this messed up code). Actual result: -- here's the backtrace: (gdb) run -r 'class Foo { private function __construct() { } function get() { self::__construct(); } } Foo::get();' Starting program: /usr/local/bin/php -r 'class Foo { private function __construct() { } function get() { self::__construct(); } } Foo::get();' [Thread debugging using libthread_db enabled] [New Thread -1214503248 (LWP 28107)] Strict Standards: Non-static method Foo::get() should not be called statically in Command line code on line 1 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1214503248 (LWP 28107)] 0x083c425c in zend_get_class_entry (zobject=0x0) at /home/sean/downloads/php-5.2.1/Zend/zend_API.c:248 248 if (Z_OBJ_HT_P(zobject)->get_class_entry) { (gdb) bt #0 0x083c425c in zend_get_class_entry (zobject=0x0) at /home/sean/downloads/php-5.2.1/Zend/zend_API.c:248 #1 0x083ec877 in ZEND_INIT_STATIC_METHOD_CALL_SPEC_UNUSED_HANDLER ( execute_data=0xbfd5e800) at /home/sean/downloads/php-5.2.1/Zend/zend_vm_execute.h:1222 #2 0x083e7fc3 in execute (op_array=0xb798f330) at /home/sean/downloads/php-5.2.1/Zend/zend_vm_execute.h:92 #3 0x083e85ed in zend_do_fcall_common_helper_SPEC (execute_data=0xbfd5e980) at /home/sean/downloads/php-5.2.1/Zend/zend_vm_execute.h:234 #4 0x083e90c0 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfd5e980) at /home/sean/downloads/php-5.2.1/Zend/zend_vm_execute.h:322 #5 0x083e7fc3 in execute (op_array=0xb798d7fc) at /home/sean/downloads/php-5.2.1/Zend/zend_vm_execute.h:92 #6 0x083b6e79 in zend_eval_string ( str=0xbfd5f911 "class Foo { private function __construct() { } function get() { self::__construct(); } } Foo::get();", retval_ptr=0x0, string_name=0x8522074 "Command line code") at /home/sean/downloads/php-5.2.1/Zend/zend_execute_API.c:1151 #7 0x083b7012 in zend_eval_string_ex ( str=0xbfd5f911 "class Foo { private function __construct() { } function get() { self::__construct(); } } Foo::get();", retval_ptr=0x0, string_name=0x8522074 "Command line code", handle_exceptions=1) at /home/sean/downloads/php-5.2.1/Zend/zend_execute_API.c:1185 #8 0x0843d555 in main (argc=3, argv=0xbfd5ed14) at /home/sean/downloads/php-5.2.1/sapi/cli/php_cli.c:1153 -- Edit this bug report at http://bugs.php.net/?id=40621&edit=1
#40621 [NEW]: Crash when constructor called inappropriately (statically)
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 5.2.1 PHP Bug Type: Reproducible crash Bug description: Crash when constructor called inappropriately (statically) Description: PHP 5.2.x (tried 5.2.1, 5.2.0) crashes if a constructor is called statically from within the host class. Code explains this better. I realize I'm not SUPPOSED to do this, but I did it accidentally (I made a mistake). I expect the error message. It shouldn't, however, crash. Reproduce code: --- php -r 'class Foo { private function __construct() { } function get() { self::__construct(); } } Foo::get();' Expected result: E_FATAL Here's 5.1.6: Fatal error: Non-static method Foo::__construct() cannot be called statically in Command line code on line 1 In 5.2.0, this was downgraded to E_STRICT, which I suspect is why it crashes (E_FATAL would have bailed, E_STRICT tries to run this messed up code). Actual result: -- here's the backtrace: (gdb) run -r 'class Foo { private function __construct() { } function get() { self::__construct(); } } Foo::get();' Starting program: /usr/local/bin/php -r 'class Foo { private function __construct() { } function get() { self::__construct(); } } Foo::get();' [Thread debugging using libthread_db enabled] [New Thread -1214503248 (LWP 28107)] Strict Standards: Non-static method Foo::get() should not be called statically in Command line code on line 1 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1214503248 (LWP 28107)] 0x083c425c in zend_get_class_entry (zobject=0x0) at /home/sean/downloads/php-5.2.1/Zend/zend_API.c:248 248 if (Z_OBJ_HT_P(zobject)->get_class_entry) { (gdb) bt #0 0x083c425c in zend_get_class_entry (zobject=0x0) at /home/sean/downloads/php-5.2.1/Zend/zend_API.c:248 #1 0x083ec877 in ZEND_INIT_STATIC_METHOD_CALL_SPEC_UNUSED_HANDLER ( execute_data=0xbfd5e800) at /home/sean/downloads/php-5.2.1/Zend/zend_vm_execute.h:1222 #2 0x083e7fc3 in execute (op_array=0xb798f330) at /home/sean/downloads/php-5.2.1/Zend/zend_vm_execute.h:92 #3 0x083e85ed in zend_do_fcall_common_helper_SPEC (execute_data=0xbfd5e980) at /home/sean/downloads/php-5.2.1/Zend/zend_vm_execute.h:234 #4 0x083e90c0 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfd5e980) at /home/sean/downloads/php-5.2.1/Zend/zend_vm_execute.h:322 #5 0x083e7fc3 in execute (op_array=0xb798d7fc) at /home/sean/downloads/php-5.2.1/Zend/zend_vm_execute.h:92 #6 0x083b6e79 in zend_eval_string ( str=0xbfd5f911 "class Foo { private function __construct() { } function get() { self::__construct(); } } Foo::get();", retval_ptr=0x0, string_name=0x8522074 "Command line code") at /home/sean/downloads/php-5.2.1/Zend/zend_execute_API.c:1151 #7 0x083b7012 in zend_eval_string_ex ( str=0xbfd5f911 "class Foo { private function __construct() { } function get() { self::__construct(); } } Foo::get();", retval_ptr=0x0, string_name=0x8522074 "Command line code", handle_exceptions=1) at /home/sean/downloads/php-5.2.1/Zend/zend_execute_API.c:1185 #8 0x0843d555 in main (argc=3, argv=0xbfd5ed14) at /home/sean/downloads/php-5.2.1/sapi/cli/php_cli.c:1153 -- Edit bug report at http://bugs.php.net/?id=40621&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40621&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40621&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40621&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40621&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40621&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40621&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40621&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40621&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40621&r=support Expected behavior:http://bugs.php.net/fix.php?id=40621&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40621&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40621&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40621&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40621&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40621&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40621&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40621&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40621&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40621&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40621&r=mysqlcfg
#40620 [NEW]: Passing by reference made on the fly does not change and no error reported
From: mano at easymail dot hu Operating system: Windows XP PHP version: 5.2.1 PHP Bug Type: Scripting Engine problem Bug description: Passing by reference made on the fly does not change and no error reported Description: I had create variables in my PHP4 application in the function-call after php4.4 new reference notice came out. It was actually working in php4.4.4 and the variable could be passed as reference: test($arr = array("ref"=>1)); I am switching to php5 and neither in php5.1 nor in php5.2 it is working or giving any error message. I believe this should work, since the variable creation has precedence over the function is passed. Anyhow, if this is another "unsolvable" problem what is so hard to do engine-wise, at least an error should be dropped like everywhere else saying "Hello, this will NOT work!" Reproduce code: --- function test(&$arr){ $arr['ref'] = 2; } test($myarr = array('ref'=>1)); $myarr2 = array('ref'=>1); test($myarr2); print_r($myarr); print_r($myarr2); Expected result: Array ( [ref] => 2 ) Array ( [ref] => 2 ) OR Notice: Only variable could pass by reference Actual result: -- Array ( [ref] => 1 ) Array ( [ref] => 2 ) -- Edit bug report at http://bugs.php.net/?id=40620&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40620&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40620&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40620&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40620&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40620&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40620&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40620&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40620&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40620&r=support Expected behavior:http://bugs.php.net/fix.php?id=40620&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40620&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40620&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40620&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40620&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40620&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40620&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40620&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40620&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40620&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40620&r=mysqlcfg
#40619 [Opn->Asn]: php5/FastCGI crash
ID: 40619 Updated by: [EMAIL PROTECTED] Reported By: test_junk at hotmail dot it -Status: Open +Status: Assigned Bug Type: Reproducible crash Operating System: Linux 2.6 PHP Version: 5.2.1 -Assigned To: +Assigned To: dmitry Previous Comments: [2007-02-24 17:28:18] test_junk at hotmail dot it - [2007-02-24 17:05:37] test_junk at hotmail dot it Description: Upgrading to 5.2.1 (even the last CVS) caused the malfuncion of several applications. We noticed the crash of apparently every script handling POST data. The configuration in use was php-5.2.1 + FastCGI + Apache 1.3.37, downgrading back to 5.2.0 resolved the problem. Reproduce code: --- test.html: Send this file: test.php Actual result: -- Internal server error -- Edit this bug report at http://bugs.php.net/?id=40619&edit=1
#40599 [Fbk->Opn]: "make test" results in segmentation fault
ID: 40599 User updated by: lyle dot pritchett at dri dot edu Reported By: lyle dot pritchett at dri dot edu -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Solaris 9, 10 PHP Version: 5CVS-2007-02-22 (snap) New Comment: Don't know if this helps, but I added --disable-inline-optimization to the configure parms; "make test" now gets a little further: (gdb) run Starting program: /opt/src/php/php5.2-200702231530/sapi/cli/php run-tests.php warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 0074 warning: Lowest section in /lib/libdl.so.1 is .dynamic at 0094 = CWD : /opt/src/php/php5.2-200702231530 PHP : sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.2.2-dev ZEND_VERSION: 2.2.0 PHP_OS : SunOS - SunOS trapdoor 5.10 Generic_118833-24 sun4u INI actual : /opt/src/php/php5.2-200702231530 More .INIs : Extra dirs : = Program received signal SIGSEGV, Segmentation fault. 0x002570c8 in _zval_ptr_dtor (zval_ptr=0xffbfb750) at /opt/src/php/php5.2-200702231530/Zend/zend_execute_API.c:412 412 (*zval_ptr)->refcount--; (gdb) bt #0 0x002570c8 in _zval_ptr_dtor (zval_ptr=0xffbfb750) at /opt/src/php/php5.2-200702231530/Zend/zend_execute_API.c:412 #1 0x00259448 in zend_call_function (fci=0xffbfb7d8, fci_cache=Variable "fci_cache" is not available. ) at zend_execute.h:155 #2 0x0019e65c in array_user_compare (a=0x64af70, b=Variable "b" is not available. ) at /opt/src/php/php5.2-200702231530/ext/standard/array.c:592 #3 0x0027b854 in zend_qsort (base=Variable "base" is not available. ) at /opt/src/php/php5.2-200702231530/Zend/zend_qsort.c:83 #4 0x002719b8 in zend_hash_sort (ht=0x621318, sort_func=0x27b75c , compar=0x19e5a4 , renumber=1, tsrm_ls=0x3ed738) at /opt/src/php/php5.2-200702231530/Zend/zend_hash.c:1275 #5 0x00198170 in zif_usort (ht=Variable "ht" is not available. ) at /opt/src/php/php5.2-200702231530/ext/standard/array.c:660 #6 0x0028a2b8 in zend_do_fcall_common_helper_SPEC (execute_data=0xffbff170, tsrm_ls=0x3ed738) at zend_vm_execute.h:200 #7 0x00293804 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xffbff170, tsrm_ls=0x3ed738) at zend_vm_execute.h:1681 #8 0x00289ae8 in execute (op_array=0x3fc678, tsrm_ls=0x3ed738) at zend_vm_execute.h:92 #9 0x0026603c in zend_execute_scripts (type=8, tsrm_ls=0x3ed738, retval=Variable "retval" is not available. ) at /opt/src/php/php5.2-200702231530/Zend/zend.c:1135 ---Type to continue, or q to quit--- #10 0x0021805c in php_execute_script (primary_file=0xffbff8dc, tsrm_ls=0x3ed738) at /opt/src/php/php5.2-200702231530/main/main.c:1787 #11 0x00306494 in main (argc=2, argv=0xffbff9e4) at /opt/src/php/php5.2-200702231530/sapi/cli/php_cli.c:1127 (gdb) Previous Comments: [2007-02-23 20:10:01] [EMAIL PROTECTED] Cannot reproduce. [2007-02-23 17:40:55] lyle dot pritchett at dri dot edu No joy. Rebuilt latest snap version (5.2-200702231530) with gcc 4.1.2. Still getting seg fault on self-test on both Solaris 9 and 10 SPARC servers. Also tried minimal config to eliminate possible effects of supplemental packages: ./configure --prefix=/opt \ --with-config-file-path=/opt/apache/conf \ --localstatedir=/var/run \ --with-libxml-dir=/opt Still barfing. Traceback on latest build same as before (with exception of absolute address values). [2007-02-23 00:45:13] [EMAIL PROTECTED] Try with GCC 4.1.2, it's working fine here on Solaris 9. [2007-02-23 00:36:07] lyle dot pritchett at dri dot edu gcc 4.1.1, built from scratch a couple of days ago. [2007-02-23 00:34:20] [EMAIL PROTECTED] What kind of GCC did you use? 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/40599 -- Edit this bug report at http://bugs.php.net/?id=40599&edit=1
#40619 [Opn]: php5/FastCGI crash
ID: 40619 User updated by: test_junk at hotmail dot it Reported By: test_junk at hotmail dot it Status: Open Bug Type: Reproducible crash Operating System: Linux 2.6 -PHP Version: 4CVS-2007-02-24 (CVS) +PHP Version: 5.2.1 New Comment: - Previous Comments: [2007-02-24 17:05:37] test_junk at hotmail dot it Description: Upgrading to 5.2.1 (even the last CVS) caused the malfuncion of several applications. We noticed the crash of apparently every script handling POST data. The configuration in use was php-5.2.1 + FastCGI + Apache 1.3.37, downgrading back to 5.2.0 resolved the problem. Reproduce code: --- test.html: Send this file: test.php Actual result: -- Internal server error -- Edit this bug report at http://bugs.php.net/?id=40619&edit=1
#40619 [NEW]: php5/FastCGI crash
From: test_junk at hotmail dot it Operating system: Linux 2.6 PHP version: 4CVS-2007-02-24 (CVS) PHP Bug Type: Reproducible crash Bug description: php5/FastCGI crash Description: Upgrading to 5.2.1 (even the last CVS) caused the malfuncion of several applications. We noticed the crash of apparently every script handling POST data. The configuration in use was php-5.2.1 + FastCGI + Apache 1.3.37, downgrading back to 5.2.0 resolved the problem. Reproduce code: --- test.html: Send this file: test.php Actual result: -- Internal server error -- Edit bug report at http://bugs.php.net/?id=40619&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40619&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40619&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40619&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40619&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40619&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40619&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40619&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40619&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40619&r=support Expected behavior:http://bugs.php.net/fix.php?id=40619&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40619&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40619&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40619&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40619&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40619&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40619&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40619&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40619&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40619&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40619&r=mysqlcfg
#39396 [Asn->Csd]: stream_set_blocking crashes
ID: 39396 Updated by: [EMAIL PROTECTED] Reported By: maurice at iceblog dot de -Status: Assigned +Status: Closed Bug Type: Streams related Operating System: Windows XP PHP Version: 5.2.0 Assigned To: pollita New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2006-11-06 16:19:29] maurice at iceblog dot de stream_socket_client should at least return FALSE or an error if you just use STREAM_CLIENT_ASYNC_CONNECT without STREAM_CLIENT_CONNECT. [2006-11-06 10:33:33] maurice at iceblog dot de Description: When you use stream_socket_client with asynchronous connect (STREAM_CLIENT_ASYNC_CONNECT), but do not specify STREAM_CLIENT_CONNECT then stream_set_blocking will crash PHP on Windows XP. The documentation does NOT tell you to use STREAM_CLIENT_ASYNC_CONNECT | STREAM_CLIENT_CONNECT. I think STREAM_CLIENT_ASYNC_CONNECT should implicate STREAM_CLIENT_CONNECT. -- Possibility 1 to fix implication - #define STREAM_XPORT_CONNECT 2 #define STREAM_XPORT_CONNECT_ASYNC 18 // instead of 16 #define PHP_STREAM_CLIENT_CONNECT4 #define PHP_STREAM_CLIENT_ASYNC_CONNECT 6 // instead of 2 -- Possibility 2 to fix "implication" --- Patch for 5.2.0 source (not CVS). --- transports.c2006-01-01 13:50:18.0 +0100 +++ transports-maurice.c2006-11-06 11:18:49.0 +0100 @@ -136,7 +136,7 @@ if ((flags & STREAM_XPORT_SERVER) == 0) { /* client */ - if (flags & STREAM_XPORT_CONNECT) { + if (flags & STREAM_XPORT_CONNECT || flags & STREAM_XPORT_CONNECT_ASYNC) { if (-1 == php_stream_xport_connect(stream, name, namelen, flags & STREAM_XPORT_CONNECT_ASYNC ? 1 : 0, timeout, &error_text, error_code TSRMLS_CC)) { - There are other (somehow) related bugs: http://bugs.php.net/bug.php?id=30386 http://bugs.php.net/bug.php?id=28245 Reproduce code: --- \n"; } else { var_dump(stream_set_blocking($fp, false)); fclose($fp); } ?> Expected result: If you do not specify STREAM_CLIENT_CONNECT in stream_socket_client the socket never ever gets connected. Thus, stream_set_blocking should return FALSE and throw an E_WARNING. However, as this is a stream function and the stream is still considered "valid", TRUE might also be all right. Under Debian Linux (Sarge, Kernel 2.6.8) stream_set_blocking returns TRUE (which I think is misleading). Actual result: -- Crashes under Windows XP; returns TRUE on Linux. -- Edit this bug report at http://bugs.php.net/?id=39396&edit=1
#28245 [NoF->Csd]: stream_Socket_client + STREAM_CLIENT_ASYNC_CONNECT = crash
ID: 28245 Updated by: [EMAIL PROTECTED] Reported By: fabrizio at zirak dot it -Status: No Feedback +Status: Closed Bug Type: *General Issues Operating System: Windows XP Pro PHP Version: 5CVS-2004-05-01 (dev) New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2004-05-09 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2004-05-01 21:55:35] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2004-05-01 20:19:42] fabrizio at zirak dot it Description: PHP5_CVS crashing when i try to specify flag STREAM_CLIENT_ASYNC_CONNECT for function stream_Socket_client(). -- Edit this bug report at http://bugs.php.net/?id=28245&edit=1
#40543 [Opn->Bgs]: pack/unpack bug
ID: 40543 Updated by: [EMAIL PROTECTED] Reported By: dedmajor at gmail dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: linux x86_64 PHP Version: 5.2.1 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php You should be using either L or V, not N. Previous Comments: [2007-02-19 13:34:38] dedmajor at gmail dot com Description: #38770 not fixed(?) in 5.2.1-dev on x86_64 AMD Opteron(tm) Processor 265 unpack don't work, on i686 Intel(R) Celeron(R) CPU 2.50GHz works fine for example. Reproduce code: --- php -r 'print_r(unpack("N", pack("N", 41445))); Expected result: Array ( [1] => 41445 ) Actual result: -- Array ( [1] => -2147442203 ) -- Edit this bug report at http://bugs.php.net/?id=40543&edit=1
#40590 [Opn->Bgs]: list($k,$v) = $v; gives unexpected output
ID: 40590 Updated by: [EMAIL PROTECTED] Reported By: black at scene-si dot org -Status: Open +Status: Bogus Bug Type: Variables related Operating System: linux PHP Version: 5.2.1 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php In PHP 5 this is the expected behavior. Previous Comments: [2007-02-22 13:26:58] black at scene-si dot org Description: list() overwriting variable, unexpected result (different from php4). Reproduce code: --- $v = array("00","-- Day --"); list($k,$v) = $v; var_dump(array($k,$v)); Expected result: Var dump should return: array(2) { [0]=> string(2) "00" [1]=> string(11) "-- Day -- " } Actual result: -- Var dump returns: array(2) { [0]=> string(1) "-" [1]=> string(11) "-- Day -- " } -- Edit this bug report at http://bugs.php.net/?id=40590&edit=1
#40609 [Opn->Asn]: Segfaults when using more than one SoapVar in a request
ID: 40609 Updated by: [EMAIL PROTECTED] Reported By: robin dot harvey at chaptereight dot com -Status: Open +Status: Assigned Bug Type: SOAP related Operating System: Linux - Ubuntu PHP Version: 5.2.1 -Assigned To: +Assigned To: dmitry Previous Comments: [2007-02-24 14:08:31] robin dot harvey at chaptereight dot com Hi, I've uploaded the Soap service to an accessible site, and produced a backtrace, as requested. I've not used dbg before, so please let me know if i've done something wrong. I recompiled php with --enable-debug: heres the configure line: './configure' \ '--with-apxs2=/usr/bin/apxs2' \ '--with-zlib' \ '--with-bz2' \ '--with-pdo-mysql' \ '--with-pdo-pgsql' \ '--with-xsl' \ '--with-pear' \ '--enable-soap' \ '--enable-ftp' \ '--with-gd' \ '--enable-mbstring' \ '--enable-sockets' \ '--with-mcrypt' \ '--enable-debug' Here's a copy of the php script I'm using: be nice for a old chum XML; $xml2 = << Run it through to see what's going on XML; $c = new SoapClient('http://bluelines.org:8080/axis2/services/StockQuoteService?wsdl'); $sv1 = new SoapVar($xml1, XSD_ANYXML); $sv2 = new SoapVar($xml2, XSD_ANYXML); $c->update(array('symbol' => $sv1, 'price' => $sv2)); ?> ...and the dbg session, with a backtrace... (gdb) set args /home/robin/tmp/40609.php (gdb) run Starting program: /usr/local/bin/php /home/robin/tmp/40609.php (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 46912533505280 (LWP 23881)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type to continue, or q to quit--- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912533505280 (LWP 23881)] 0x00642c51 in encode_add_ns () (gdb) bt #0 0x00642c51 in encode_add_ns () #1 0x00639c62 in to_zval_user () #2 0x00639f42 in to_zval_user () #3 0x0063a71d in to_zval_user () #4 0x006420d5 in sdl_guess_convert_xml () #5 0x00634b37 in master_to_xml () #6 0x0062c8c6 in add_soap_fault () #7 0x0062c781 in add_soap_fault () #8 0x0062ba97 in add_soap_fault () #9 0x00624448 in zim_SoapClient_SoapClient () #10 0x00625f40 in zim_SoapClient___call () #11 0x007fd2f8 in zend_call_function () #12 0x00827112 in zend_call_method () #13 0x00830aca in zend_std_call_user_call () #14 0x00834ecd in execute () #15 0x00835daa in execute () #16 0x00834912 in execute () #17 0x0080c9e8 in zend_execute_scripts () #18 0x007ae109 in php_execute_script () #19 0x0089170a in main () Many thanks, --Robin [2007-02-23 17:48:16] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. An accessible WSDL might also be helpful [2007-02-23 17:12:38] robin dot harvey at chaptereight dot com Description: I've got a very simple soap service (written in Java/Tomcat/Axis) which simply accepts and logs the XML of a soap request. I need to post complex XML to the server (an XSL stylesheet) and I'm using SoapVar with XSD_ANYXML and dealing with the XSL as a string in PHP. When I try to add more than one SoapVar object encoded in this way, PHP segfaults. It's happy with 1 param as a SoapVar, and with both as simple strings. Reproduce code: --- http://192.168.1.79:8080/axis2/services/BuddyTestService?wsdl'); $data1 = << the transform go here! XML; $data2 = << Random content sent to the soap server XML; $tdata = new SoapVar($data1, XSD_ANYXML); $
#40506 [Opn->Bgs]: comment
ID: 40506 Updated by: [EMAIL PROTECTED] Reported By: php at koterov dot ru -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: all PHP Version: 5.2.1 New Comment: Right, input != output but with PHP 5 we can't know the input character set so we need to make the best possible choice and that's UTF-8. And don't forget that changing the expected encoding now would break any application using that functionality. (This will change with PHP 6 where we'll have the full character set information available) Previous Comments: [2007-02-24 14:00:06] php at koterov dot ru I understand that JSON is UTF8-based format. But the question was different: why json_encode() wastes CPU time for analyze the input data instead of passing it through? And the second thought. Assume that the output of json_encode must be UTF8, OK. But why should it limit us to use UTF8 as its input parameter? Ideologically input != output. The main disadvantage that I cannot iterate through all of the input data and call iconv() for it before passing the resulting array to json_encode(). Because it is very CPU expensive (e.g. if I transfer more than 500 strings, each about 30 characters length, the slowdown is great). Theoretically json_encode() is irreplaceable for fast execution and CPU saving only, but it is totally impossible in non-UTF8 sites. Because of the speed is not needed, it is very easy to use PHP version of this function. I think that if we want to follow the RFC literally, it may be better to write json_encode() without any encoding analyzation, and after that - call iconv() ONE TIME to convert the resulting string to UTF8. It is much more faster than calling of iconv() for each input string. Maybe - pass the second optional parameter, $src_encoding, to json_encode() to specify input encoding. [2007-02-17 15:50:14] [EMAIL PROTECTED] http://www.ietf.org/rfc/rfc4627.txt?number=4627 see section 3 [2007-02-16 10:47:31] php at koterov dot ru Description: Could you please explain why json_encode() takes care about the encoding at all? Why not to treat all the string data as a binary flow? This is very inconvenient and disallows the usage of json_encode() in non-UTF8 sites! :-( I have written a small substitution for json_encode(), but note that it of course works much more slow than json_encode() with big data arrays.. /** * Convert PHP scalar, array or hash to JS scalar/array/hash. */ function php2js($a) { if (is_null($a)) return 'null'; if ($a === false) return 'false'; if ($a === true) return 'true'; if (is_scalar($a)) { $a = addslashes($a); $a = str_replace("\n", '\n', $a); $a = str_replace("\r", '\r', $a); $a = preg_replace('{($v) $result[] = php2js($k) . ': ' . php2js($v); return '{ ' . join(', ', $result) . ' }'; } } So, my suggestion is remove all string analyzation from json_encode() code. It also make this function to work faster. Reproduce code: --- 'проверка', 'b' => array('слуха', 'глухого')); echo json_encode($a); ?> Expected result: Correctly encoded string in the source 1-byte encoding. Actual result: -- Empty strings everywhere (and sometimes - notices that a string contains non-UTF8 characters). -- Edit this bug report at http://bugs.php.net/?id=40506&edit=1
#40618 [NEW]: Exception in callback methoid leads to fatal Error
From: ludwig at gramberg-webdesign dot de Operating system: Windows 2000 PHP version: 5.2.1 PHP Bug Type: PCRE related Bug description: Exception in callback methoid leads to fatal Error Description: If a function called by preg_replace_callback throws an exception this exception is not propagated up to the function which called preg_replace_callback. Instead a PHP error is produced. This error contains no information about what the problem was or where it occurred. Reproduce code: --- Expected result: code to output Yay, exception! Actual result: -- Warning: preg_replace_callback(): Unable to call custom replacement function on line 13 -- Edit bug report at http://bugs.php.net/?id=40618&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40618&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40618&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40618&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40618&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40618&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40618&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40618&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40618&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40618&r=support Expected behavior:http://bugs.php.net/fix.php?id=40618&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40618&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40618&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40618&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40618&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40618&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40618&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40618&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40618&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40618&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40618&r=mysqlcfg
#40609 [Fbk->Opn]: Segfaults when using more than one SoapVar in a request
ID: 40609 User updated by: robin dot harvey at chaptereight dot com Reported By: robin dot harvey at chaptereight dot com -Status: Feedback +Status: Open Bug Type: SOAP related Operating System: Linux - Ubuntu PHP Version: 5.2.1 New Comment: Hi, I've uploaded the Soap service to an accessible site, and produced a backtrace, as requested. I've not used dbg before, so please let me know if i've done something wrong. I recompiled php with --enable-debug: heres the configure line: './configure' \ '--with-apxs2=/usr/bin/apxs2' \ '--with-zlib' \ '--with-bz2' \ '--with-pdo-mysql' \ '--with-pdo-pgsql' \ '--with-xsl' \ '--with-pear' \ '--enable-soap' \ '--enable-ftp' \ '--with-gd' \ '--enable-mbstring' \ '--enable-sockets' \ '--with-mcrypt' \ '--enable-debug' Here's a copy of the php script I'm using: be nice for a old chum XML; $xml2 = << Run it through to see what's going on XML; $c = new SoapClient('http://bluelines.org:8080/axis2/services/StockQuoteService?wsdl'); $sv1 = new SoapVar($xml1, XSD_ANYXML); $sv2 = new SoapVar($xml2, XSD_ANYXML); $c->update(array('symbol' => $sv1, 'price' => $sv2)); ?> ...and the dbg session, with a backtrace... (gdb) set args /home/robin/tmp/40609.php (gdb) run Starting program: /usr/local/bin/php /home/robin/tmp/40609.php (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 46912533505280 (LWP 23881)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type to continue, or q to quit--- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912533505280 (LWP 23881)] 0x00642c51 in encode_add_ns () (gdb) bt #0 0x00642c51 in encode_add_ns () #1 0x00639c62 in to_zval_user () #2 0x00639f42 in to_zval_user () #3 0x0063a71d in to_zval_user () #4 0x006420d5 in sdl_guess_convert_xml () #5 0x00634b37 in master_to_xml () #6 0x0062c8c6 in add_soap_fault () #7 0x0062c781 in add_soap_fault () #8 0x0062ba97 in add_soap_fault () #9 0x00624448 in zim_SoapClient_SoapClient () #10 0x00625f40 in zim_SoapClient___call () #11 0x007fd2f8 in zend_call_function () #12 0x00827112 in zend_call_method () #13 0x00830aca in zend_std_call_user_call () #14 0x00834ecd in execute () #15 0x00835daa in execute () #16 0x00834912 in execute () #17 0x0080c9e8 in zend_execute_scripts () #18 0x007ae109 in php_execute_script () #19 0x0089170a in main () Many thanks, --Robin Previous Comments: [2007-02-23 17:48:16] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. An accessible WSDL might also be helpful [2007-02-23 17:12:38] robin dot harvey at chaptereight dot com Description: I've got a very simple soap service (written in Java/Tomcat/Axis) which simply accepts and logs the XML of a soap request. I need to post complex XML to the server (an XSL stylesheet) and I'm using SoapVar with XSD_ANYXML and dealing with the XSL as a string in PHP. When I try to add more than one SoapVar object encoded in this way, PHP segfaults. It's happy with 1 param as a SoapVar, and with both as simple strings. Reproduce code: --- http://192.168.1.79:8080/axis2/services/BuddyTestService?wsdl'); $data1 = << the transform go here! XML; $data2 = << Random content sent to the soap server XML; $tdata = new SoapVar($data1, XSD_ANYXML); $t = new SoapVar($data2, XSD_ANYXML); $data = array('TransformData' => $tdata, 'Transform' => $t); //$data = array('TransformData' => 'foo', 'Trans
#40506 [Bgs->Opn]: comment
ID: 40506 User updated by: php at koterov dot ru -Summary: Suggestion: json_encode() and non-UTF8 strings Reported By: php at koterov dot ru -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: all PHP Version: 5.2.1 New Comment: I understand that JSON is UTF8-based format. But the question was different: why json_encode() wastes CPU time for analyze the input data instead of passing it through? And the second thought. Assume that the output of json_encode must be UTF8, OK. But why should it limit us to use UTF8 as its input parameter? Ideologically input != output. The main disadvantage that I cannot iterate through all of the input data and call iconv() for it before passing the resulting array to json_encode(). Because it is very CPU expensive (e.g. if I transfer more than 500 strings, each about 30 characters length, the slowdown is great). Theoretically json_encode() is irreplaceable for fast execution and CPU saving only, but it is totally impossible in non-UTF8 sites. Because of the speed is not needed, it is very easy to use PHP version of this function. I think that if we want to follow the RFC literally, it may be better to write json_encode() without any encoding analyzation, and after that - call iconv() ONE TIME to convert the resulting string to UTF8. It is much more faster than calling of iconv() for each input string. Maybe - pass the second optional parameter, $src_encoding, to json_encode() to specify input encoding. Previous Comments: [2007-02-17 15:50:14] [EMAIL PROTECTED] http://www.ietf.org/rfc/rfc4627.txt?number=4627 see section 3 [2007-02-16 10:47:31] php at koterov dot ru Description: Could you please explain why json_encode() takes care about the encoding at all? Why not to treat all the string data as a binary flow? This is very inconvenient and disallows the usage of json_encode() in non-UTF8 sites! :-( I have written a small substitution for json_encode(), but note that it of course works much more slow than json_encode() with big data arrays.. /** * Convert PHP scalar, array or hash to JS scalar/array/hash. */ function php2js($a) { if (is_null($a)) return 'null'; if ($a === false) return 'false'; if ($a === true) return 'true'; if (is_scalar($a)) { $a = addslashes($a); $a = str_replace("\n", '\n', $a); $a = str_replace("\r", '\r', $a); $a = preg_replace('{($v) $result[] = php2js($k) . ': ' . php2js($v); return '{ ' . join(', ', $result) . ' }'; } } So, my suggestion is remove all string analyzation from json_encode() code. It also make this function to work faster. Reproduce code: --- 'проверка', 'b' => array('слуха', 'глухого')); echo json_encode($a); ?> Expected result: Correctly encoded string in the source 1-byte encoding. Actual result: -- Empty strings everywhere (and sometimes - notices that a string contains non-UTF8 characters). -- Edit this bug report at http://bugs.php.net/?id=40506&edit=1
#40611 [Csd->Opn]: cURL memory error
ID: 40611 User updated by: zamorov at edinorog dot ru Reported By: zamorov at edinorog dot ru -Status: Closed +Status: Open Bug Type: cURL related Operating System: FreeBSD 4.11 PHP Version: 4CVS-2007-02-23 (snap) Assigned To: tony2001 New Comment: I get snapshot build on Feb 24, 2007 09:30 GMT Memory bug still not fixed. Add before: curl_setopt($curl, CURLOPT_URL, 'http://bar-navig.yandex.ru/u?sample=test'); $return = curl_exec($curl); this line curl_setopt($curl, CURLOPT_URL, 'http://bar-navig.yandex.ru/u?ver=2&lang=1049&ur l=www.php.net&target=_No__Name:5&show=1&thc=0'); $return = curl_exec($curl); and reload a script of 10-20 times. Previous Comments: [2007-02-23 20:53:39] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2007-02-23 18:05:35] zamorov at edinorog dot ru Description: cURL 1.15.5, 1.16.0 and 1.16.1 Got many error in log if request site with empty body. Sample: http://bar-navig.yandex.ru/u?sample=test HTTP/1.1 200 Ok Connection: close Cache-control: no-cache, max-age=0 Expires: Thu, 01 Jan 1970 00:00:01 GMT Content-Type: text/html; charset=windows-1251 and no body. Reproduce code: --- http://bar-navig.yandex.ru/u?sample=test'); $return = curl_exec($curl); echo (curl_errno($this->Curl) == 0) ? 'ok' : 'error'; ?> Expected result: error.log many lines with httpd in free(): warning: page is already free httpd in free(): warning: chunk is already free and Integer overflow in memory_limit check detected Actual result: -- Zero page. -- Edit this bug report at http://bugs.php.net/?id=40611&edit=1
#40600 [Bgs]: [PATCH]:getgrgid_r, getgrnam_r etc functions regression(crash)
ID: 40600 User updated by: stas at FreeBSD dot org Reported By: stas at FreeBSD dot org Status: Bogus Bug Type: POSIX related Operating System: FreeBSD PHP Version: 5.2.1 Assigned To: iliaa New Comment: > The current code is fine, we should not hardcode buffer > sizes if they cannot be retrieved, this could lead to > exploitable situations. Also if the return buffer length of > 0 it probably indicates a problem. 1) According to POSIX it's not a problem 2) Besides that one check is missing (take a look at patch), so you're effectively trying to malloc (size_t)-1 bytes on FreeBSD currently, which leads to crash. Previous Comments: [2007-02-23 23:53:25] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The current code is fine, we should not hardcode buffer sizes if they cannot be retrieved, this could lead to exploitable situations. Also if the return buffer length of 0 it probably indicates a problem. [2007-02-23 14:07:38] [EMAIL PROTECTED] Ilia, please take a look at this, IIRC you added those sysconf() patches. [2007-02-23 13:55:02] [EMAIL PROTECTED] >Yeah... According to susv3: Yes, I know that, thanks. But that does not mean "if (buflen < 1)" is incorrect. I don't think that zero buflen is a correct value (and even if it is, it's useless). [2007-02-23 13:47:59] stas at FreeBSD dot org >>This patch covers two problems: >>1) The POSIX says that sysconf will return -1 on failure, >> thus the ( < check is definitely incorrect > >Oh? Care to elaborate? Yeah... According to susv3: "If name is an invalid value, sysconf() shall return -1 and set errno to indicate the error. If the variable corresponding to name has no limit, sysconf() shall return -1 without changing the value of errno. Note that indefinite limits do not imply infinite limits; see ." >>2) It's safe to use the buffer of any size (according to >> POSIX), since you give the buffer length to these >> functions. > >Yeah, according to POSIX those functions must be >implemented. >But they are not. >it's better then give up on retriving this info just in >case the sysconf doesn't has these limit values. >I don't think it's any better to use hacks to workaround >missing FreeBSD > functionality. Ok, agree. It's open to you. [2007-02-23 12:22:20] [EMAIL PROTECTED] >This patch covers two problems: >1) The POSIX says that sysconf will return -1 on failure, > thus the ( < check is definitely incorrect Oh? Care to elaborate? >2) It's safe to use the buffer of any size (according to > POSIX), since you give the buffer length to these > functions. Yeah, according to POSIX those functions must be implemented. But they are not. >it's better then give up on retriving this info just in >case the sysconf doesn't has these limit values. I don't think it's any better to use hacks to workaround missing FreeBSD functionality. 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/40600 -- Edit this bug report at http://bugs.php.net/?id=40600&edit=1
#40417 [Bgs]: Suddenly binding as many vars as there are *identical* prepared tokens
ID: 40417 User updated by: exaton at free dot fr Reported By: exaton at free dot fr Status: Bogus Bug Type: PDO related Operating System: Windows XP Pro SP2 PHP Version: 5.2.1 New Comment: Wow. I'm flabbergasted. Mr Alshanetsky, I am, as they say, and until further notice, disappointed in you. No update of the CVS code. Not even a note in the manual to reflect this spec change. I guess this is going to have to wait until someone else reports it. It's got to be relatively common, especially in not too complex search engine implementations. Until then, therefore... Previous Comments: [2007-02-24 03:19:49] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . [2007-02-16 11:26:30] exaton at free dot fr Hey again people, I don't mean to be annoying, but I've just done a bit more research, so I thought I'd share it with you. Iliaa, I found the code change where you added the infamous spec-altering error check that I'm going on about : PHP_5_2 : http://cvs.php.net/viewcvs.cgi/php-src/ext/pdo/pdo_sql_parser.c?r1=1.35.2.6.2.3&r2=1.35.2.6.2.4 Also applied to MAIN, with both times the comment : "Added missing check for mismatching number of tokens & bound params in prepared statement emulation." That perfectly matches my error conditions. The problem is, the bindno variable contains the number of individual tokens. However, multiple tokens may have the same name ; but each token name can only be bound once ! So comparing bindno to the number of bindings is incorrect. It introduces the following specification : "multiple tokens may not have the same name in a prepared statement". The workaround is still the same : binding enough bogus tokens to match the number of individual tokens used in the prepared statement, when some share the same name. Oh, did I mention that this prevented anyone with prepared statements containing multiple tokens sharing the same name from upgrading to PHP 5.2.1 ? :-) [2007-02-10 17:18:20] exaton at free dot fr OK, I've taken a look at the source code to try and lend a hand in clearing up this issue. My first time though, so here's hoping I'm not too far off the mark. Diffing ext/pdo/ and ext/pdo_pgsql/ files between PHP 5.2.0 and 5.2.1, I find that the error message I am encountering is due to a new paragraph having been *added* to the much remangled ext/pdo/pdo_sql_parser.c (line 262) : if (params && bindno != zend_hash_num_elements(params) && stmt->supports_placeholders == PDO_PLACEHOLDER_NONE) { pdo_raise_impl_error(stmt->dbh, stmt, "HY093", "number of bound variables does not match number of tokens" TSRMLS_CC); ret = -1; goto clean_up; } Somehow I'm trigerring the error condition, here. I'm guessing that my bindno is different from the number of elements in the params hash table. bindno is incremented on line 214. I could be wrong, but I'm under the impression that it is *incremented with each _placeholder_*, which in turn I take to be the "token *instances*" we were talking about before. Now, I think we both agree that we only have to bind as many values/vars as there are *different* tokens in the statement. That is in any case how things worked up to PHP 5.2.0. With the new error detection that has been added (the above paragraph of code), and if I'm right about the way bindno is counted, then we are expected to bind as many values/vars as there are *placeholders* in the statement, even if there are 2 or more placeholders for the same token name. That would be very coherent with the new error I am getting. It would also be coherent with my workaround, in which one just had to bind extra, bogus values/vars (thus artificially filling up the params hash table, with params = stmt -> bound_params) in order to not get this error. So : 1) The new error detection breaks existing scripts that worked with 5.2.0. 2) I think we agree that the specification introduced by this new error detection is incorrect. One may, as far as I know, use several times the same placeholder for bound values/vars in a statement. It is only possible to bind a given token once (because that binding fills a hash table, which will of course not increase in size if the same token is bound several times). Therefore, forcing one to bind as many values/vars as there are *placeholders* is surely incorrect. 3) The workaround is symptomatic of something real fishy going on (having to write bogus code to "unblock" a piece of functionality, wt... ?). That's as much as I can do guys, I have no setup whatsoever for tracing