[PHP-BUG] Bug #51417 [NEW]: getLineNo always returns 0 when called from DOMText nodes
From: Operating system: linux 2.6.24 PHP version: 5.3.2 Package: DOM XML related Bug Type: Bug Bug description:getLineNo always returns 0 when called from DOMText nodes Description: The getLineNo() method exists for DOMText but doesn't work correctly; it always returns 0. Test script: --- baz EOF; $doc = new DOMDocument(); $doc->loadXML( $xml ); $text = $doc->documentElement->firstChild->nextSibling->firstChild; echo get_class( $text ) . ' : ' . $text->data . ' : ' . $text->getLineNo() . "\n"; ?> Expected result: DOMText : baz : 2 Actual result: -- DOMText : baz : 0 -- Edit bug report at http://bugs.php.net/bug.php?id=51417&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51417&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51417&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51417&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51417&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51417&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51417&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51417&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51417&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51417&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51417&r=support Expected behavior: http://bugs.php.net/fix.php?id=51417&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51417&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51417&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51417&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51417&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51417&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51417&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51417&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51417&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51417&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51417&r=mysqlcfg
Bug #51298 [Com]: Error when loading php5apache2_2.dll
Edit report at http://bugs.php.net/bug.php?id=51298&edit=1 ID: 51298 Comment by: jeftyneg at yahoo dot com Reported by: trotsky_icepick at hotmail dot com Summary: Error when loading php5apache2_2.dll Status: Feedback Type: Bug Package: Apache2 related Operating System: Windows Vista SP2 PHP Version: 5.3.2 Assigned To: pajoye New Comment: Any update of this critical issue? I think thorough testing was not performed against Apache 2.2.15 due to the fact that Apache 2.2.15 was released 2 days after PHP 5.3.2 was released. Maybe there's a compatibility issue between Apache 2.2.15 and PHP 5.3.2. I personally considered this as a critical bug because this is a blocking issue. One can't proceed with testing the PHP scripts because installation can cause Apache 2.2.15 to crash. Previous Comments: [2010-03-24 15:32:25] jeftyneg at yahoo dot com Did you perform any special steps why you can't reproduce it anymore? Because in my case, I can always replicate the bug. Other user also can replicate the bug as noted in [2010-03-23 13:05 UTC]. OS: Windows XP with SP3(Fresh installation with updates from Microsoft) PHP: 5.3.2 Apache: 2.2.15 Installation options used are all default. I just can't imagine why you can't replicate the bug but in our environment, it can easily be replicated. Please tell us more about your test environment. Thanks. [2010-03-23 16:01:19] paj...@php.net I can't reproduce it anymore, clean install for both Windows and PHP. I also tested the installer on all supported windows version with apache 2.2.15, it went like a charm. [2010-03-23 15:05:44] hfastt at hotmail dot com Same problem here. Installed Apache 2.2.15 [httpd-2.2.15-win32-x86-openssl-0.9.8m-r2.msi] and PHP 5.2.13 [php-5.2.13-Win32-VC6-x86.msi] (or PHP 5.3.2 [php-5.3.2-Win32-VC6-x86.msi]) on Windows XP SP3. When I try to start Apache, it crashes with Error signature: szAppName : httpd.exe szAppVer : 2.2.15.0 szModName : php5ts.dll szModVer : 5.2.13.13 offset : 000f352a [2010-03-23 13:46:10] jeftyneg at yahoo dot com Sorry for late feedback. I have already tried http://pecl2.php.net/downloads/php-windows-builds/qa/test/php-5.3.2-win32-VC6-x86-installer.msi but the problem still exists. Apache still crashed when loading php5apache2_2.dll module. Steps to reproduce are same as noted in [2010-03-21 11:32 UTC]. [2010-03-22 20:03:48] paj...@php.net Can you try using please: http://pecl2.php.net/downloads/php-windows-builds/qa/test/php-5.3.2-win32-VC6-x86-installer.msi 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/bug.php?id=51298 -- Edit this bug report at http://bugs.php.net/bug.php?id=51298&edit=1
[PHP-BUG] Req #51416 [NEW]: douchebag
From: Operating system: none PHP version: Irrelevant Package: Unknown/Other Function Bug Type: Feature/Change Request Bug description:douchebag Description: stream_get_contents ( resource $handle [, int $maxlength = -1 [, int $offset = 0 ]] ) in any culture (if you have not been made with pie) you are pointing a direction from an origin, e.g a vector (mid-school) stream_get_contents (handle , location , length) -- Edit bug report at http://bugs.php.net/bug.php?id=51416&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51416&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51416&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51416&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51416&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51416&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51416&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51416&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51416&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51416&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51416&r=support Expected behavior: http://bugs.php.net/fix.php?id=51416&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51416&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51416&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51416&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51416&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51416&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51416&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51416&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51416&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51416&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51416&r=mysqlcfg
Bug #51415 [Opn->Asn]: htaccess and mbstring.func_overload does not set local value
Edit report at http://bugs.php.net/bug.php?id=51415&edit=1 ID: 51415 Updated by: fel...@php.net Reported by: giorgio dot liscio at email dot it Summary: htaccess and mbstring.func_overload does not set local value -Status: Open +Status: Assigned Type: Bug Package: mbstring related Operating System: windows xp x64 PHP Version: 5.3.2 -Assigned To: +Assigned To: moriyoshi Previous Comments: [2010-03-27 22:46:07] giorgio dot liscio at email dot it Description: hi php_value mbstring.func_overload 3 does not works on 5.3.2 in the same htaccess -absolutely working- file php_value mbstring.internal_encoding "UTF-8" works correctly func_overload does not on my host i have the same problem and my hoster absolutely thinks that is a php bug http://www.php.net/manual/en/mbstring.overload.php#91023 buggy since 5.2.7 too thank you in advance -- Edit this bug report at http://bugs.php.net/bug.php?id=51415&edit=1
[PHP-BUG] Bug #51415 [NEW]: htaccess and mbstring.func_overload does not set local value
From: Operating system: windows xp x64 PHP version: 5.3.2 Package: mbstring related Bug Type: Bug Bug description:htaccess and mbstring.func_overload does not set local value Description: hi php_value mbstring.func_overload 3 does not works on 5.3.2 in the same htaccess -absolutely working- file php_value mbstring.internal_encoding "UTF-8" works correctly func_overload does not on my host i have the same problem and my hoster absolutely thinks that is a php bug http://www.php.net/manual/en/mbstring.overload.php#91023 buggy since 5.2.7 too thank you in advance -- Edit bug report at http://bugs.php.net/bug.php?id=51415&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51415&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51415&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51415&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51415&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51415&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51415&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51415&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51415&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51415&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51415&r=support Expected behavior: http://bugs.php.net/fix.php?id=51415&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51415&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51415&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51415&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51415&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51415&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51415&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51415&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51415&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51415&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51415&r=mysqlcfg
Bug #51405 [Opn]: segmentation fault at the "engine shutdown"
Edit report at http://bugs.php.net/bug.php?id=51405&edit=1 ID: 51405 User updated by: miha dot vrhovnik at domenca dot com Reported by: miha dot vrhovnik at domenca dot com Summary: segmentation fault at the "engine shutdown" Status: Open Type: Bug Package: Reproducible crash Operating System: Linux PHP Version: 5.3.2 New Comment: Just so there won't be any excuses that this is because I'm running under php-fpm Here is backtrace from apache2. a bit different configure -- removed fpm and added apache: ./configure '--with-apxs2=/usr/bin/apxs2' '--with-openssl' '--with-zlib' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--with-curl' '--enable-exif' '--enable-ftp' '--with-gd' '--with-imap' '--with-imap-ssl' '--enable-mbstring' '--with-mcrypt' '--enable-pcntl' '--with-pdo-mysql' '--with-pdo-pgsql' '--with-pgsql' '--with-readline' '--with-mysql' '--enable-soap' '--enable-sockets' '--enable-sqlite-utf8' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-tidy' '--enable-wddx' '--with-xmlrpc' '--with-xsl' '--enable-zip' '--with-kerberos' '--with-mysqli' '--with-config-file-path=/usr/local/etc' '--with-config-file-scan-dir=/usr/local/etc/php.d' '--with-pear' '--with-jpeg-dir=/usr/lib' --with-freetype-dir=/usr/lib and now the actual backtrace (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. _zend_mm_free_int (heap=0xb979d180, p=0xb9946290) at /projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c:2018 2018/projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c: No such file or directory. in /projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c (gdb) bt #0 _zend_mm_free_int (heap=0xb979d180, p=0xb9946290) at /projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c:2018 #1 0xb6ff2498 in zend_hash_destroy (ht=0xba189ca0) at /projects/php53/php-fpm-5.3.2/Zend/zend_hash.c:526 #2 0xb7003fc3 in zend_object_std_dtor (object=0xba193830) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:45 #3 0xb7003ff2 in zend_objects_free_object_storage (object=0xba193830) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:114 #4 0xb70075fc in zend_objects_store_del_ref_by_handle_ex (handle=127, handlers=0xb74c65c0) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects_API.c:220 #5 0xb700762f in zend_objects_store_del_ref (zobject=0xba189ff0) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects_API.c:172 #6 0xb6fdbedf in _zval_dtor (zval_ptr=0xba1a6238) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.h:35 #7 _zval_ptr_dtor (zval_ptr=0xba1a6238) at /projects/php53/php-fpm-5.3.2/Zend/zend_execute_API.c:439 #8 0xb6ff2498 in zend_hash_destroy (ht=0xba19273c) at /projects/php53/php-fpm-5.3.2/Zend/zend_hash.c:526 #9 0xb6fe6945 in _zval_dtor_func (zvalue=0xba197ef4) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.c:43 #10 0xb6fdbedf in _zval_dtor (zval_ptr=0xba106080) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.h:35 ---Type to continue, or q to quit--- #11 _zval_ptr_dtor (zval_ptr=0xba106080) at /projects/php53/php-fpm-5.3.2/Zend/zend_execute_API.c:439 #12 0xb6ff2498 in zend_hash_destroy (ht=0xba12276c) at /projects/php53/php-fpm-5.3.2/Zend/zend_hash.c:526 #13 0xb7003fc3 in zend_object_std_dtor (object=0xb5e7013c) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:45 #14 0xb7003ff2 in zend_objects_free_object_storage (object=0xb5e7013c) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:114 #15 0xb70075fc in zend_objects_store_del_ref_by_handle_ex (handle=120, handlers=0xb74c65c0) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects_API.c:220 #16 0xb700762f in zend_objects_store_del_ref (zobject=0xba051424) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects_API.c:172 #17 0xb6fdbedf in _zval_dtor (zval_ptr=0xba1ac560) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.h:35 #18 _zval_ptr_dtor (zval_ptr=0xba1ac560) at /projects/php53/php-fpm-5.3.2/Zend/zend_execute_API.c:439 #19 0xb6ff2498 in zend_hash_destroy (ht=0xb9dbc140) at /projects/php53/php-fpm-5.3.2/Zend/zend_hash.c:526 #20 0xb6fe6945 in _zval_dtor_func (zvalue=0xb9d45c40) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.c:43 #21 0xb6fdbedf in _zval_dtor (zval_ptr=0xb9dc1130) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.h:35 ---Type to continue, or q to quit--- #22 _zval_ptr_dtor (zval_ptr=0xb9dc1130) at /projects/php53/php-fpm-5.3.2/Zend/zend_execute_API.c:439 #23 0xb6ff2498 in zend_hash_destroy (ht=0xb9d4a5fc) at /projects/php53/php-fpm-5.3.2/Zend/zend_hash.c:526 #24 0xb7003fc3 in zend_object_std_dtor (object=0xb9dc3df4) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:45 #25 0xb7003ff2 in zend_objects_free_object_storage (object=0xb9dc3df4) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:114 #26 0xb70075fc in zend_objects_store_del_ref_b
Bug #51413 [Wfx]: ereg() no longer works as in earlier versions
Edit report at http://bugs.php.net/bug.php?id=51413&edit=1 ID: 51413 Updated by: ras...@php.net Reported by: rprangnell at gmail dot com Summary: ereg() no longer works as in earlier versions Status: Wont fix Type: Bug Package: Program Execution Operating System: Windows XP PHP Version: 5.3.2 New Comment: It is not for no apparent reason. It is because they upgraded without reading the UPGRADING documentation. Previous Comments: [2010-03-27 17:52:30] rprangnell at gmail dot com I can well appreciate why this bug is not going to be fixed - after all, the ereg() function is now officially deprecated and should be replaced by the preg_match() function. However, there must be many applications out there that are still using ereg() and which will therefore suddenly break for no apparent reason whenever the companies hosting such applications upgrade to later versions of PHP. [2010-03-27 17:14:48] ras...@php.net Probably part of bringing everything under the same parameter handling code. This will have to be fixed in your application. And they really shouldn't be using ereg() anymore anyway. It is slower and doesn't support Unicode at all. All ereg() calls should be replaced with preg_match() calls. You will notice that the call will also throw an E_DEPRECATED warning in 5.3 letting you know you should be replacing those calls. [2010-03-27 17:03:16] rprangnell at gmail dot com Description: PHP scripts that use the ereg() function and which worked properly in earlier versions may no longer work because of a change in the way ereg() deals with function arguments. Namely, ereg() now seems to check the "expected argument" type and throws an error if the argument is of a different type. I came across this bug on a brand new, clean install of Drupal 6.3 with the Ubercart ecommerce package. With PHP 5.3 running, certain images would not display and multiple warning messages would pop up, each of them detailing the culprit as ereg(). Simply by changing the running PHP version to 5.2.11 cured all problems. -- Edit this bug report at http://bugs.php.net/bug.php?id=51413&edit=1
Bug #51413 [Wfx]: ereg() no longer works as in earlier versions
Edit report at http://bugs.php.net/bug.php?id=51413&edit=1 ID: 51413 User updated by: rprangnell at gmail dot com Reported by: rprangnell at gmail dot com Summary: ereg() no longer works as in earlier versions Status: Wont fix Type: Bug Package: Program Execution Operating System: Windows XP PHP Version: 5.3.2 New Comment: I can well appreciate why this bug is not going to be fixed - after all, the ereg() function is now officially deprecated and should be replaced by the preg_match() function. However, there must be many applications out there that are still using ereg() and which will therefore suddenly break for no apparent reason whenever the companies hosting such applications upgrade to later versions of PHP. Previous Comments: [2010-03-27 17:14:48] ras...@php.net Probably part of bringing everything under the same parameter handling code. This will have to be fixed in your application. And they really shouldn't be using ereg() anymore anyway. It is slower and doesn't support Unicode at all. All ereg() calls should be replaced with preg_match() calls. You will notice that the call will also throw an E_DEPRECATED warning in 5.3 letting you know you should be replacing those calls. [2010-03-27 17:03:16] rprangnell at gmail dot com Description: PHP scripts that use the ereg() function and which worked properly in earlier versions may no longer work because of a change in the way ereg() deals with function arguments. Namely, ereg() now seems to check the "expected argument" type and throws an error if the argument is of a different type. I came across this bug on a brand new, clean install of Drupal 6.3 with the Ubercart ecommerce package. With PHP 5.3 running, certain images would not display and multiple warning messages would pop up, each of them detailing the culprit as ereg(). Simply by changing the running PHP version to 5.2.11 cured all problems. -- Edit this bug report at http://bugs.php.net/bug.php?id=51413&edit=1
Bug #51413 [Opn->Wfx]: ereg() no longer works as in earlier versions
Edit report at http://bugs.php.net/bug.php?id=51413&edit=1 ID: 51413 Updated by: ras...@php.net Reported by: rprangnell at gmail dot com Summary: ereg() no longer works as in earlier versions -Status: Open +Status: Wont fix Type: Bug Package: Program Execution Operating System: Windows XP PHP Version: 5.3.2 New Comment: Probably part of bringing everything under the same parameter handling code. This will have to be fixed in your application. And they really shouldn't be using ereg() anymore anyway. It is slower and doesn't support Unicode at all. All ereg() calls should be replaced with preg_match() calls. You will notice that the call will also throw an E_DEPRECATED warning in 5.3 letting you know you should be replacing those calls. Previous Comments: [2010-03-27 17:03:16] rprangnell at gmail dot com Description: PHP scripts that use the ereg() function and which worked properly in earlier versions may no longer work because of a change in the way ereg() deals with function arguments. Namely, ereg() now seems to check the "expected argument" type and throws an error if the argument is of a different type. I came across this bug on a brand new, clean install of Drupal 6.3 with the Ubercart ecommerce package. With PHP 5.3 running, certain images would not display and multiple warning messages would pop up, each of them detailing the culprit as ereg(). Simply by changing the running PHP version to 5.2.11 cured all problems. -- Edit this bug report at http://bugs.php.net/bug.php?id=51413&edit=1
[PHP-BUG] Bug #51413 [NEW]: ereg() no longer works as in earlier versions
From: Operating system: Windows XP PHP version: 5.3.2 Package: Program Execution Bug Type: Bug Bug description:ereg() no longer works as in earlier versions Description: PHP scripts that use the ereg() function and which worked properly in earlier versions may no longer work because of a change in the way ereg() deals with function arguments. Namely, ereg() now seems to check the "expected argument" type and throws an error if the argument is of a different type. I came across this bug on a brand new, clean install of Drupal 6.3 with the Ubercart ecommerce package. With PHP 5.3 running, certain images would not display and multiple warning messages would pop up, each of them detailing the culprit as ereg(). Simply by changing the running PHP version to 5.2.11 cured all problems. -- Edit bug report at http://bugs.php.net/bug.php?id=51413&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51413&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51413&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51413&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51413&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51413&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51413&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51413&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51413&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51413&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51413&r=support Expected behavior: http://bugs.php.net/fix.php?id=51413&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51413&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51413&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51413&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51413&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51413&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51413&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51413&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51413&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51413&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51413&r=mysqlcfg
Bug #51412 [Com]: inconsistency using uninitialized array elements
Edit report at http://bugs.php.net/bug.php?id=51412&edit=1 ID: 51412 Comment by: zingus at gmail dot com Reported by: looris at gmail dot com Summary: inconsistency using uninitialized array elements Status: Bogus Type: Bug Package: Arrays related Operating System: linux, osx, (any?) PHP Version: Irrelevant New Comment: Another script, further highlighting the inconsistence, and the fact it isn't an array bug, but one of unary decrease operator (or of the += and -= operators) Result: --- $a['z']--; array ( 'z' => NULL, ) $b['z']+=-1; array ( 'z' => -1, ) $c-=1; -1 $d--; NULL Previous Comments: [2010-03-27 15:07:05] johan...@php.net The documentation claims The increment/decrement operators do not affect boolean values. Decrementing NULL values has no effect too, but incrementing them results in 1. http://php.net/manual/en/language.operators.increment.php This might be considered inconsistent but changing this would be a rather random compatibility break. [2010-03-27 15:00:22] looris at gmail dot com Description: While I agree that it would be better to actually initialize elements before using them, it is anyway wrong that they behave in inconsistent ways when you do that. They should BOTH count as 0, hence become 1 and -1, OR they should **BOTH** stay NULL. It does not make any sense at all to have them behave in two different ways. Test script: --- $pitale=array(); $pitale["ok"]++; $pitale["bug"]--; print_r($pitale); Expected result: Array ( [ok] => 1 [bug] => -1 ) ---OR--- Array ( [ok] => [bug] => ) Actual result: -- Array ( [ok] => 1 [bug] => ) -- Edit this bug report at http://bugs.php.net/bug.php?id=51412&edit=1
Bug #51412 [Opn->Bgs]: inconsistency using uninitialized array elements
Edit report at http://bugs.php.net/bug.php?id=51412&edit=1 ID: 51412 Updated by: johan...@php.net Reported by: looris at gmail dot com Summary: inconsistency using uninitialized array elements -Status: Open +Status: Bogus Type: Bug Package: Arrays related Operating System: linux, osx, (any?) PHP Version: Irrelevant New Comment: The documentation claims The increment/decrement operators do not affect boolean values. Decrementing NULL values has no effect too, but incrementing them results in 1. http://php.net/manual/en/language.operators.increment.php This might be considered inconsistent but changing this would be a rather random compatibility break. Previous Comments: [2010-03-27 15:00:22] looris at gmail dot com Description: While I agree that it would be better to actually initialize elements before using them, it is anyway wrong that they behave in inconsistent ways when you do that. They should BOTH count as 0, hence become 1 and -1, OR they should **BOTH** stay NULL. It does not make any sense at all to have them behave in two different ways. Test script: --- $pitale=array(); $pitale["ok"]++; $pitale["bug"]--; print_r($pitale); Expected result: Array ( [ok] => 1 [bug] => -1 ) ---OR--- Array ( [ok] => [bug] => ) Actual result: -- Array ( [ok] => 1 [bug] => ) -- Edit this bug report at http://bugs.php.net/bug.php?id=51412&edit=1
[PHP-BUG] Bug #51412 [NEW]: inconsistency using uninitialized array elements
From: Operating system: linux, osx, (any?) PHP version: Irrelevant Package: Arrays related Bug Type: Bug Bug description:inconsistency using uninitialized array elements Description: While I agree that it would be better to actually initialize elements before using them, it is anyway wrong that they behave in inconsistent ways when you do that. They should BOTH count as 0, hence become 1 and -1, OR they should **BOTH** stay NULL. It does not make any sense at all to have them behave in two different ways. Test script: --- $pitale=array(); $pitale["ok"]++; $pitale["bug"]--; print_r($pitale); Expected result: Array ( [ok] => 1 [bug] => -1 ) ---OR--- Array ( [ok] => [bug] => ) Actual result: -- Array ( [ok] => 1 [bug] => ) -- Edit bug report at http://bugs.php.net/bug.php?id=51412&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51412&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51412&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51412&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51412&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51412&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51412&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51412&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51412&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51412&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51412&r=support Expected behavior: http://bugs.php.net/fix.php?id=51412&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51412&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51412&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51412&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51412&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51412&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51412&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51412&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51412&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51412&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51412&r=mysqlcfg
Bug #51155 [Fbk->Opn]: serialize() crashes with unreasonable/unexplicable "out of memory" for objects
Edit report at http://bugs.php.net/bug.php?id=51155&edit=1 ID: 51155 User updated by: flavius dot as at gmail dot com Reported by: flavius dot as at gmail dot com Summary: serialize() crashes with unreasonable/unexplicable "out of memory" for objects -Status: Feedback +Status: Open Type: Bug Package: SPL related Operating System: ArchLinux x86_64 -PHP Version: 5.3.1 +PHP Version: 5.3.2 New Comment: updated version Previous Comments: [2010-03-04 15:10:04] flavius dot as at gmail dot com Ok, I've managed to compile and test with php5.3-201003041130, the bug is still there, but it seems to crash for higher values. for 2 items, the peak is peak 21.71 mb before serialize, peak 45.59 mb after serialize. simple maths: it should need approximatively 5 mb for every 5000 items. The following test run for 25000 confirms my theory (roughly, +/- due to temporarily saving the return value, runtime memory, etc): before serialization: peak 26.98 mb after: peak 56.7 mb Ok, it's slightly higher than 5mb, after serialization is a small increase over the expected (which I presumed) 2*n linear growth. Now the final run. But first and foremost $ sapi/cli/php -i |grep memory memory_limit => 128M => 128M And the test run, for 3 items: GENERATING DONE peak 32.24 mb --- Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 28574231 bytes) The expected value was somewhere around (and I'll be generous) 80mb. But I suppose it still has that spark of exponential growth somewhere between 25000 and 3 items. [2010-03-04 14:30:17] paj...@php.net That's unrelated to this bug, disable imap to test a new build. However, about this error, get a decent c-client and it will work (like less than 4-5 years old). [2010-03-04 14:26:28] flavius dot as at gmail dot com Using it gives the configure error: configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing. This should not happen. Check config.log for additional information. [2010-03-01 17:02:22] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-02-26 13:41:59] flavius dot as at gmail dot com Oh and I've forgot to mention, there's plenty of RAM and swap space before running php -f: free -m total used free sharedbuffers cached Mem: 1975 1732243 0131 1027 -/+ buffers/cache:573 1402 Swap: 5718 0 5718 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/bug.php?id=51155 -- Edit this bug report at http://bugs.php.net/bug.php?id=51155&edit=1
Bug #51396 [Fbk]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Updated by: johan...@php.net Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: You are mentioned this version information: php -v PHP 5.2.4-2ubuntu5.10 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6 2010 22:01:14) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Zend Debugger v5.2.15, Copyright (c) 1999-2008, by Zend Technologies This version is very different from the versions we provide. a) Ubuntu adds some custom patches b) Suhosin does major changes to the engine c) Xdebug as well as Zend Debugger do changes to our executor unit. All these components aren't supported here. Previous Comments: [2010-03-27 12:50:58] codeslinger at compsalot dot com One further note, in the repro above, it has to be exactly 16 nines. by adding or removing a 9, it does not fail. Also, as far as I know, all of the failures have been on 32bit Intel cpu's. This probably will not fail on a 64bit cpu. [2010-03-27 12:22:12] codeslinger at compsalot dot com well, it's hard to prove a negative. but I have run a bunch of tests on the Linux snapshot and it appears to be working fine. A VERY BIG THANKYOU I did not find any windows snapshots, the latest is 5.2.13 from Feb 24. based on the symptoms, my initial assumption was that this was caused by some kind of array corruption, this turned out to be wrong. the actual repro can be boiled down to one line... :-) echo (string) (double) -0.0; With the caveat that there are other values which also trigger this. [2010-03-26 21:37:12] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-03-26 21:32:51] codeslinger at compsalot dot com as far as the low incidence of occurrence and the millions of users not seeing it. I've said all along that it is hard to reproduce. But when dealing with financial transactions, that is not good enough, it only takes one mistake to have a huge problem on your hands. Out of all of those millions of users, I'd venture to say that the very overwhelming majority are using php for string processing not number crunching. And in many cases where it does show up such as positioning something on a web page, it would be easy to shrug off. So there is no way to know how often this happens in the wild, based on user feedback. [2010-03-26 21:02:47] codeslinger at compsalot dot com The billing program was failing on multiple computers at multiple locations, it failed on XP and Windows 2000 with various cpus. Those were customer sites! I reproduced the problem on a vmware setup with windows 2000. This snowflake program is failing on Ubuntu Hardy 8.0.4 with all of the updates. This is the stock php that comes with Ubuntu. This is a Pentium M 32bit Laptop. I've never experienced a memory error on this computer and the fact of it's consistency would argue against this being some kind of hardware issue. Here is what I get when I run the simplefail in the default config. php -v PHP 5.2.4-2ubuntu5.10 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6 2010 22:01:14) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Zend Debugger v5.2.15, Copyright (c) 1999-2008, by Zend Technologies == php simplefail.php Selected onepair.txt, Found 1 items (string)(double) -0.1 === -0.1 which of course is correct But when we convert the value in an array it fails Conversion Error: PHP Math idx = 0 || '-0.1' !== '-0.0:' = THANK YOU I REALLY APPRECIATE THE HELP 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/bug.php?id=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396&edit=1
Bug #51411 [Opn->Bgs]: mysql_connect()
Edit report at http://bugs.php.net/bug.php?id=51411&edit=1 ID: 51411 Updated by: johan...@php.net Reported by: modig at rediffmail dot com Summary: mysql_connect() -Status: Open +Status: Bogus Type: Bug Package: MySQL related Operating System: RHEL 5.4 PHP Version: 5.2.13 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. You should always use the named MYSQL_* constants - I have no idea what 128 stands for. Make sure you're assigning the return value of mysql_query to a variable and use that as connection identifier everywhere. Previous Comments: [2010-03-27 14:02:32] modig at rediffmail dot com Description: Dear Supporter We have two mysql based server both are running same version of o/s, and mysql. One is acting as master and another one is acting as report server. The report server is basically replicating data from master server. >From one another server which is acting a web server we are connecting both server. All though we are not pointing any data manipulation commands/queries to report server, our report(replication) server is getting such query. We are connecting our both servers with below function "mysql_connect(server, user, pwd, false , 128) What I am doubting is the fourth parameter is not behaving or returning some abnormal connection from stack. Please update me if I am wrong or give me some more specific input on this. Mr. Devang Modi For FSTPL India Gujarat -- Edit this bug report at http://bugs.php.net/bug.php?id=51411&edit=1
[PHP-BUG] Bug #51411 [NEW]: mysql_connect()
From: Operating system: RHEL 5.4 PHP version: 5.2.13 Package: MySQL related Bug Type: Bug Bug description: mysql_connect() Description: Dear Supporter We have two mysql based server both are running same version of o/s, and mysql. One is acting as master and another one is acting as report server. The report server is basically replicating data from master server. >From one another server which is acting a web server we are connecting both server. All though we are not pointing any data manipulation commands/queries to report server, our report(replication) server is getting such query. We are connecting our both servers with below function "mysql_connect(server, user, pwd, false , 128) What I am doubting is the fourth parameter is not behaving or returning some abnormal connection from stack. Please update me if I am wrong or give me some more specific input on this. Mr. Devang Modi For FSTPL India Gujarat -- Edit bug report at http://bugs.php.net/bug.php?id=51411&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51411&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51411&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51411&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51411&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51411&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51411&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51411&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51411&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51411&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51411&r=support Expected behavior: http://bugs.php.net/fix.php?id=51411&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51411&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51411&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51411&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51411&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51411&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51411&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51411&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51411&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51411&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51411&r=mysqlcfg
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: One further note, in the repro above, it has to be exactly 16 nines. by adding or removing a 9, it does not fail. Also, as far as I know, all of the failures have been on 32bit Intel cpu's. This probably will not fail on a 64bit cpu. Previous Comments: [2010-03-27 12:22:12] codeslinger at compsalot dot com well, it's hard to prove a negative. but I have run a bunch of tests on the Linux snapshot and it appears to be working fine. A VERY BIG THANKYOU I did not find any windows snapshots, the latest is 5.2.13 from Feb 24. based on the symptoms, my initial assumption was that this was caused by some kind of array corruption, this turned out to be wrong. the actual repro can be boiled down to one line... :-) echo (string) (double) -0.0; With the caveat that there are other values which also trigger this. [2010-03-26 21:37:12] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-03-26 21:32:51] codeslinger at compsalot dot com as far as the low incidence of occurrence and the millions of users not seeing it. I've said all along that it is hard to reproduce. But when dealing with financial transactions, that is not good enough, it only takes one mistake to have a huge problem on your hands. Out of all of those millions of users, I'd venture to say that the very overwhelming majority are using php for string processing not number crunching. And in many cases where it does show up such as positioning something on a web page, it would be easy to shrug off. So there is no way to know how often this happens in the wild, based on user feedback. [2010-03-26 21:02:47] codeslinger at compsalot dot com The billing program was failing on multiple computers at multiple locations, it failed on XP and Windows 2000 with various cpus. Those were customer sites! I reproduced the problem on a vmware setup with windows 2000. This snowflake program is failing on Ubuntu Hardy 8.0.4 with all of the updates. This is the stock php that comes with Ubuntu. This is a Pentium M 32bit Laptop. I've never experienced a memory error on this computer and the fact of it's consistency would argue against this being some kind of hardware issue. Here is what I get when I run the simplefail in the default config. php -v PHP 5.2.4-2ubuntu5.10 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6 2010 22:01:14) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Zend Debugger v5.2.15, Copyright (c) 1999-2008, by Zend Technologies == php simplefail.php Selected onepair.txt, Found 1 items (string)(double) -0.1 === -0.1 which of course is correct But when we convert the value in an array it fails Conversion Error: PHP Math idx = 0 || '-0.1' !== '-0.0:' = THANK YOU I REALLY APPRECIATE THE HELP [2010-03-26 17:25:40] ahar...@php.net Well, it is the next character after '9', and the character string is built up in zend_dtoa() by adding a value L (presumably intended to be in the range 0..9) to '0'. If L somehow ends up being 10, you'd get a colon. With the values that are apparently causing problems (the problematic value in onepair.txt is 0.0167...), it does kind of look like a rounding issue to me, although I've no idea why it's not being triggered by more than two or three users in that case. 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/bug.php?id=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396&edit=1
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: well, it's hard to prove a negative. but I have run a bunch of tests on the Linux snapshot and it appears to be working fine. A VERY BIG THANKYOU I did not find any windows snapshots, the latest is 5.2.13 from Feb 24. based on the symptoms, my initial assumption was that this was caused by some kind of array corruption, this turned out to be wrong. the actual repro can be boiled down to one line... :-) echo (string) (double) -0.0; With the caveat that there are other values which also trigger this. Previous Comments: [2010-03-26 21:37:12] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-03-26 21:32:51] codeslinger at compsalot dot com as far as the low incidence of occurrence and the millions of users not seeing it. I've said all along that it is hard to reproduce. But when dealing with financial transactions, that is not good enough, it only takes one mistake to have a huge problem on your hands. Out of all of those millions of users, I'd venture to say that the very overwhelming majority are using php for string processing not number crunching. And in many cases where it does show up such as positioning something on a web page, it would be easy to shrug off. So there is no way to know how often this happens in the wild, based on user feedback. [2010-03-26 21:02:47] codeslinger at compsalot dot com The billing program was failing on multiple computers at multiple locations, it failed on XP and Windows 2000 with various cpus. Those were customer sites! I reproduced the problem on a vmware setup with windows 2000. This snowflake program is failing on Ubuntu Hardy 8.0.4 with all of the updates. This is the stock php that comes with Ubuntu. This is a Pentium M 32bit Laptop. I've never experienced a memory error on this computer and the fact of it's consistency would argue against this being some kind of hardware issue. Here is what I get when I run the simplefail in the default config. php -v PHP 5.2.4-2ubuntu5.10 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6 2010 22:01:14) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Zend Debugger v5.2.15, Copyright (c) 1999-2008, by Zend Technologies == php simplefail.php Selected onepair.txt, Found 1 items (string)(double) -0.1 === -0.1 which of course is correct But when we convert the value in an array it fails Conversion Error: PHP Math idx = 0 || '-0.1' !== '-0.0:' = THANK YOU I REALLY APPRECIATE THE HELP [2010-03-26 17:25:40] ahar...@php.net Well, it is the next character after '9', and the character string is built up in zend_dtoa() by adding a value L (presumably intended to be in the range 0..9) to '0'. If L somehow ends up being 10, you'd get a colon. With the values that are apparently causing problems (the problematic value in onepair.txt is 0.0167...), it does kind of look like a rounding issue to me, although I've no idea why it's not being triggered by more than two or three users in that case. [2010-03-26 17:18:22] ras...@php.net Bad memory perhaps? But why consistently a ':' ? 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/bug.php?id=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396&edit=1
