Bug #55475 [Com]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1 ID: 55475 Comment by: alan at akbkhome dot com Reported by:mads at gartneriet dot dk Summary:is_a() triggers autoloader Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.3.7 Assigned To:dmitry Block user comment: N Private report: N New Comment: >From the manual. "Returns TRUE if the object is of this class or has this class as one of its parents, FALSE otherwise." note the "FALSE otherwise" ... Defiantly a bug.. Previous Comments: [2011-08-23 05:17:52] mads at gartneriet dot dk DB_DataObject uses is_a() to check if a variable is both an object and an instance of a particular object. PEAR::isError() does too. This just gives warnings in my code, and I could of course easily fix these two places in my local pear-code. But then it will bite me the next time I upgrade those packages from PEAR. [2011-08-22 21:46:19] col...@php.net What code? Do you have some example? [2011-08-22 19:17:28] mads at gartneriet dot dk Maybe not a bug, but it is behaving different ind 5.3.7 than in the previous versions, which makes some of the code from PEAR that i use, give errors. [2011-08-22 18:36:59] s...@php.net This is not a bug. If first argument is a string, it is interpreted as a class name and autoloader is called for it. Actually, IIRC, one the reasons why is_a was un-deprecated is that it can work with strings. [2011-08-22 15:46:05] johan...@php.net is_a()'s first argument is documented to be an object. If called with a string, following the documentation, I would actually expect a "Warning: is_a() expects parameter 1 to be object, string given" and return NULL. That aside and looking at the actual behavior: Previously is_a() could be used to check whether the parameter is an object AND of a specific type in one go. This can't be done anymore. In $a = "test"; is_a($a, "foo"); test might be an existing class and might be of type foo. Now people have to do is_object() && is_a(). I don't like having such behavior change in bug fix versions as I don't like going back and forth which is annoying for documentation and confusing for users. I would love to keep it out of 5.3.8 to have that as low risk quick release for the hash issue. Which means a rollback to the old way is even harder to do. (two versions with the new behavior out) 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 https://bugs.php.net/bug.php?id=55475 -- Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55483 [Asn->Csd]: extra > at the end of html tag in phpinfo
Edit report at https://bugs.php.net/bug.php?id=55483&edit=1
ID: 55483
Updated by: ahar...@php.net
Reported by:chadm at codeangel dot org
Summary:extra > at the end of html tag in phpinfo
-Status: Assigned
+Status: Closed
Type: Bug
Package:PHP options/info functions
PHP Version:5.4SVN-2011-08-23 (SVN)
Assigned To:aharvey
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-08-23 06:07:16] ahar...@php.net
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=315332
Log: Fix bug #55483 (extra > at the end of html tag in phpinfo).
[2011-08-23 05:15:05] chadm at codeangel dot org
Description:
in ext/standard/info.c:
line 629PUTS("http://www.w3.org/1999/xhtml\";>>");
note the extra >
Test script:
---
--
Edit this bug report at https://bugs.php.net/bug.php?id=55483&edit=1
Bug #55483 [Opn->Asn]: extra > at the end of html tag in phpinfo
Edit report at https://bugs.php.net/bug.php?id=55483&edit=1
ID: 55483
Updated by: ahar...@php.net
Reported by:chadm at codeangel dot org
Summary:extra > at the end of html tag in phpinfo
-Status: Open
+Status: Assigned
Type: Bug
Package:PHP options/info functions
PHP Version:5.4SVN-2011-08-23 (SVN)
-Assigned To:
+Assigned To:aharvey
Block user comment: N
Private report: N
Previous Comments:
[2011-08-23 05:15:05] chadm at codeangel dot org
Description:
in ext/standard/info.c:
line 629PUTS("http://www.w3.org/1999/xhtml\";>>");
note the extra >
Test script:
---
--
Edit this bug report at https://bugs.php.net/bug.php?id=55483&edit=1
[PHP-BUG] Bug #55485 [NEW]: Compile ERROR: undefined symbol: xmlParserInputBufferCreateFilenameDefault
From: Operating system: Red Hat Enterprise Linux Server PHP version: 5.3.7 Package: Compile Failure Bug Type: Bug Bug description:Compile ERROR: undefined symbol: xmlParserInputBufferCreateFilenameDefault Description: ./configure '--prefix=/usr/local/php532' '--with-config-file-path=/usr/local/php532/lib' '--disable-debug' '--disable-rpath' ' --enable-inline-optimization' '--with-curl' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-iconv' '--with- pcre-regex' '--with-zlib' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enabl e-sysvsem' '--enable-sysvshm' '--enable-wddx' '--with-pear' '--with-kerberos' '--with-ldap' '--with-mysql' '--with-mysqli' '-- with-pgsql' '--enable-ucd-snmp-hack' '--enable-shmop' '--enable-calendar' '--enable-mbstring=shared' '--enable-mbregex' '--ena ble-pcntl' '--with-gd' '--with-jpeg-dir=/usr/lib' make Expected result: PHP gets compiled Actual result: -- ... Generating phar.php /usr/local/src/php-5.3.7/sapi/cli/php: symbol lookup error: /usr/local/src/php-5.3.7/sapi/cli/php: undefined symbol: xmlParserInputBufferCreateFilenameDefault make: *** [ext/phar/phar.php] Error 127 -- Edit bug report at https://bugs.php.net/bug.php?id=55485&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55485&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55485&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55485&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55485&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55485&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55485&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55485&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55485&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55485&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55485&r=support Expected behavior: https://bugs.php.net/fix.php?id=55485&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55485&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55485&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55485&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55485&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55485&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55485&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55485&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55485&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55485&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55485&r=mysqlcfg
Bug #55475 [Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1 ID: 55475 User updated by:mads at gartneriet dot dk Reported by:mads at gartneriet dot dk Summary:is_a() triggers autoloader Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.3.7 Assigned To:dmitry Block user comment: N Private report: N New Comment: DB_DataObject uses is_a() to check if a variable is both an object and an instance of a particular object. PEAR::isError() does too. This just gives warnings in my code, and I could of course easily fix these two places in my local pear-code. But then it will bite me the next time I upgrade those packages from PEAR. Previous Comments: [2011-08-22 21:46:19] col...@php.net What code? Do you have some example? [2011-08-22 19:17:28] mads at gartneriet dot dk Maybe not a bug, but it is behaving different ind 5.3.7 than in the previous versions, which makes some of the code from PEAR that i use, give errors. [2011-08-22 18:36:59] s...@php.net This is not a bug. If first argument is a string, it is interpreted as a class name and autoloader is called for it. Actually, IIRC, one the reasons why is_a was un-deprecated is that it can work with strings. [2011-08-22 15:46:05] johan...@php.net is_a()'s first argument is documented to be an object. If called with a string, following the documentation, I would actually expect a "Warning: is_a() expects parameter 1 to be object, string given" and return NULL. That aside and looking at the actual behavior: Previously is_a() could be used to check whether the parameter is an object AND of a specific type in one go. This can't be done anymore. In $a = "test"; is_a($a, "foo"); test might be an existing class and might be of type foo. Now people have to do is_object() && is_a(). I don't like having such behavior change in bug fix versions as I don't like going back and forth which is annoying for documentation and confusing for users. I would love to keep it out of 5.3.8 to have that as low risk quick release for the hash issue. Which means a rollback to the old way is even harder to do. (two versions with the new behavior out) [2011-08-22 14:49:31] col...@php.net Well, we have 3 options here: 1) keep it like it is since 5.3.7 2) reverting it to how it worked before 5.3.7 3) change it even more to not use autoload, so that it neither works like <5.3.6 nor 5.3.7 Apparently through your proposed fix you're advocating for (3). If so, I can't see how it would improve the situation in any way. Personally, given that the BC change is minimal, and that we're only adding functionality, (1) seems fine. Correct code existing before 5.3.6 will work just fine anyway. 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 https://bugs.php.net/bug.php?id=55475 -- Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
[PHP-BUG] Bug #55484 [NEW]: file upload bug..
From: Operating system: windows PHP version: 5.3.7 Package: Built-in web server Bug Type: Bug Bug description:file upload bug.. Description: --- POST - Array ( [bo_image_head] => Array ( [name] => Y [type] => [tmp_name] => [error] => 4 [size] => 0 ) [bo_image_tail] => Array ( [name] => [type] => [tmp_name] => [error] => 4 [size] => 0 ) ) [name] => Y <-- bug Test script: --- asas --- POST - Array ( [bo_image_head] => Array ( [name] => Y [type] => [tmp_name] => [error] => 4 [size] => 0 ) [bo_image_tail] => Array ( [name] => [type] => [tmp_name] => [error] => 4 [size] => 0 ) ) [name] => Y <-- bug -- Edit bug report at https://bugs.php.net/bug.php?id=55484&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55484&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55484&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55484&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55484&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55484&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55484&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55484&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55484&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55484&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55484&r=support Expected behavior: https://bugs.php.net/fix.php?id=55484&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55484&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55484&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55484&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55484&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55484&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55484&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55484&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55484&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55484&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55484&r=mysqlcfg
[PHP-BUG] Bug #55483 [NEW]: extra > at the end of html tag in phpinfo
From:
Operating system:
PHP version: 5.4SVN-2011-08-23 (SVN)
Package: PHP options/info functions
Bug Type: Bug
Bug description:extra > at the end of html tag in phpinfo
Description:
in ext/standard/info.c:
line 629PUTS("http://www.w3.org/1999/xhtml\";>>");
note the extra >
Test script:
---
--
Edit bug report at https://bugs.php.net/bug.php?id=55483&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55483&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55483&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55483&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55483&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55483&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55483&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55483&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55483&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55483&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55483&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55483&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55483&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55483&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55483&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55483&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55483&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55483&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55483&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55483&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55483&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55483&r=mysqlcfg
Req #55464 [Opn->Bgs]: differ is_float() from is_double()
Edit report at https://bugs.php.net/bug.php?id=55464&edit=1 ID: 55464 Updated by: cataphr...@php.net Reported by:zandor_zz at yahoo dot it Summary:differ is_float() from is_double() -Status: Open +Status: Bogus Type: Feature/Change Request Package:Variables related Operating System: any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: There is only one floating point type in PHP -- it is named float, with "double" (and "real") as an alias and the underlying representation is a C double. Both is_float and is_double (and also is_real) test for this type. So the proposal makes no sense. As such, I'm closing this as bogus. What I think you actually wanted to suggest is introducing a new type with single precision. This would be a rather big change with no compelling advantages (the double can represent all the values the float can) and possible BC breaks. In any case, such a change would require extended discussion; see https://wiki.php.net/rfc Previous Comments: [2011-08-19 20:02:14] zandor_zz at yahoo dot it Description: It would be nice to differ the behavior of is_float() from is_double(). This situation is not consistent cause float and double do differ for different byte size. I have created a PHP class to handle advanced read/write operations on files and I crashed onto this ambiguous situation. Thus I wrote myself a workaround to solve this ambiguous situation. Then I suggest that it would be nice to rely on this feature in the standard PHP library. Test script: --- It is known from PHP standard documentation that is_double() is an alias of is_float(). -- Edit this bug report at https://bugs.php.net/bug.php?id=55464&edit=1
[PHP-BUG] Bug #55482 [NEW]: if --enable-maintainer-zts, compile failed.
From: Operating system: CENT OS 5.4 PHP version: 5.3.7 Package: Compile Failure Bug Type: Bug Bug description:if --enable-maintainer-zts, compile failed. Description: # ./configure--enable-maintainer-zts # make ext/standard/info.o: In function `php_info_print_table_header': /home/modify/php537/src/ext/standard/info.c:1107: undefined reference to `ts_resource_ex' ext/standard/info.o: In function `php_info_print_table_row_internal': /home/modify/php537/src/ext/standard/info.c:1151: undefined reference to `ts_resource_ex' ext/standard/info.o: In function `php_print_gpcse_array': /home/modify/php537/src/ext/standard/info.c:149: undefined reference to `executor_globals_id' ext/standard/info.o: In function `php_info_write_wrapper': /home/modify/php537/src/ext/standard/info.c:80: undefined reference to `ts_resource_ex' ext/standard/info.o: In function `php_print_info': /home/modify/php537/src/ext/standard/info.c:975: undefined reference to `executor_globals_id' /home/modify/php537/src/ext/standard/info.c:978: undefined reference to `executor_globals_id' /home/modify/php537/src/ext/standard/info.c:981: undefined reference to `executor_globals_id' /home/modify/php537/src/ext/standard/info.c:984: undefined reference to `executor_globals_id' /home/modify/php537/src/ext/standard/info.c:906: undefined reference to `sapi_globals_id' /home/modify/php537/src/ext/standard/info.c:680: undefined reference to `sapi_globals_id' /home/modify/php537/src/ext/standard/info.c:885: undefined reference to `sapi_globals_id' collect2: ld returned 1 exit status make: *** [sapi/cgi/php-cgi] é误 1 -- Edit bug report at https://bugs.php.net/bug.php?id=55482&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55482&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55482&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55482&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55482&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55482&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55482&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55482&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55482&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55482&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55482&r=support Expected behavior: https://bugs.php.net/fix.php?id=55482&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55482&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55482&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55482&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55482&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55482&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55482&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55482&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55482&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55482&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55482&r=mysqlcfg
[PHP-BUG] Bug #55481 [NEW]: Bug in reading Arabic valules form files
From: Operating system: CentOS PHP version: 5.3SVN-2011-08-23 (SVN) Package: *PDF functions Bug Type: Bug Bug description:Bug in reading Arabic valules form files Description: its was in 5.3.6 latest version in Cpanle and its show the vales as >>"" Test script: --- Expected result: Ù Ø٠د Actual result: -- ØØØØ -- Edit bug report at https://bugs.php.net/bug.php?id=55481&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55481&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55481&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55481&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55481&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55481&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55481&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55481&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55481&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55481&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55481&r=support Expected behavior: https://bugs.php.net/fix.php?id=55481&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55481&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55481&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55481&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55481&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55481&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55481&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55481&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55481&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55481&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55481&r=mysqlcfg
Bug #50696 [Com]: number_format when passed a 0 as first function argument, returns null
Edit report at https://bugs.php.net/bug.php?id=50696&edit=1 ID: 50696 Comment by: jacob at jacobweber dot com Reported by:endosquid at endosquid dot com Summary:number_format when passed a 0 as first function argument, returns null Status: Wont fix Type: Bug Package:Math related Operating System: Linux 32 bit PHP Version:5.3.1 Block user comment: N Private report: N New Comment: Fun thread! Anyway, I was wondering if anyone has a complete list of the functions that changed as a result of this zend_parse_parameters() fix. I don't see anything specific in the upgrade instructions: http://www.php.net/manual/en/migration53.incompatible.php Also, will number_format((float) $x) behave under PHP 5.3.x exactly the same way that number_format($x) behaved under PHP 5.2.x? Are there any subtle differences? Thanks. Previous Comments: [2010-01-08 23:47:19] bj...@php.net Sir. This issue was recently brought to my attention. On behalf of PHP I would like to apologize. I see that now that you have been treated unfairly. After carefully reviewing this bug report with our board of directors on 4chan, we have come to the conclusion that your "rusty C skills" should be enough to fix the issue. I would therefore like to remind you that ras...@php.net is http://en.wikipedia.org/wiki/Rasmus_lerdorf Again, I sincerely apologize. We will try to stop fixing bugs in PHP. [2010-01-08 23:22:52] endosquid at endosquid dot com Just look in the mirror, pal. You need classes on how to listen to others. [2010-01-08 23:20:13] ras...@php.net Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure. [2010-01-08 23:05:43] endosquid at endosquid dot com I get it. Yours is bigger, you've worked better, you are at the cutting edge of everything, and you have infinite resources to test every new version of every piece of software in your stack. Got it. I'm shamed and have no options. So, you're going to give a cover-all answer to make sure that you don't have to do anything. Ok, I get it. I hope no one ever does this to you, because it makes you lose faith in the product. We will push forwrd with patching the source. It would appear that the 1194th line in math.c is the one that needs changing. returning 0 as opposed to returning nothing? I'll edit and compile. [2010-01-08 22:47:04] ras...@php.net I have worked in such environments. Much bigger ones, in fact. Part of your responsibility in your position is to keep track of your tools and the changes coming down the pipeline. 5.3 was available to you as a release candidate in March of last year, and even earlier directly from our revision control system. Many things have changed and there are many many people out there affected by these changes, we recognize that. That is also why we are not likely to reverse a change like this that others in your situation have now accounted for, tested and deployed in production for many months simply because it is inconvenient for you. 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 https://bugs.php.net/bug.php?id=50696 -- Edit this bug report at https://bugs.php.net/bug.php?id=50696&edit=1
Bug #52461 [Csd->Asn]: phpinfo() corrections
Edit report at https://bugs.php.net/bug.php?id=52461&edit=1
ID: 52461
Updated by: paj...@php.net
Reported by:virsacer at web dot de
Summary:phpinfo() corrections
-Status: Closed
+Status: Assigned
Type: Bug
Package:*General Issues
PHP Version:5.3.3
Assigned To:pajoye
Block user comment: N
Private report: N
Previous Comments:
[2011-08-23 00:01:40] neweracracker at gmail dot com
Hi guys,
I guess you did something wrong here:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/standard/info.c?r1=315170&r2=315169&pathrev=315170
Pierre?
PUTS("http://www.w3.org/1999/xhtml\";>>");
should have been:
PUTS("http://www.w3.org/1999/xhtml\";>");
[2011-08-19 10:00:11] paj...@php.net
This bug has been fixed in SVN.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
[2011-08-19 09:59:40] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=315170
Log: - Fixed bug #52461 (Incomplete doctype and missing xmlns)
[2010-12-08 16:38:11] virsacer at web dot de
"Bug Type" is now bug
[2010-12-08 16:27:06] virsacer at web dot de
New patch contains only bug corrections.
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
https://bugs.php.net/bug.php?id=52461
--
Edit this bug report at https://bugs.php.net/bug.php?id=52461&edit=1
Bug #52461 [Com]: phpinfo() corrections
Edit report at https://bugs.php.net/bug.php?id=52461&edit=1
ID: 52461
Comment by: neweracracker at gmail dot com
Reported by:virsacer at web dot de
Summary:phpinfo() corrections
Status: Closed
Type: Bug
Package:*General Issues
PHP Version:5.3.3
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
Hi guys,
I guess you did something wrong here:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/standard/info.c?r1=315170&r2=315169&pathrev=315170
Pierre?
PUTS("http://www.w3.org/1999/xhtml\";>>");
should have been:
PUTS("http://www.w3.org/1999/xhtml\";>");
Previous Comments:
[2011-08-19 10:00:11] paj...@php.net
This bug has been fixed in SVN.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
[2011-08-19 09:59:40] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=315170
Log: - Fixed bug #52461 (Incomplete doctype and missing xmlns)
[2010-12-08 16:38:11] virsacer at web dot de
"Bug Type" is now bug
[2010-12-08 16:27:06] virsacer at web dot de
New patch contains only bug corrections.
[2010-08-09 19:34:48] ka...@php.net
The DTD is alright, as you can simply just referer to DTD/w3-ns, but its not
really a major issue but should go into trunk anyway. Ill look at an improved
patch during the week
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=52461
--
Edit this bug report at https://bugs.php.net/bug.php?id=52461&edit=1
Bug #55414 [Com]: Segmentation fault with MySQLi_Result::fetch_fields()
Edit report at https://bugs.php.net/bug.php?id=55414&edit=1
ID: 55414
Comment by: lgandras at gmail dot com
Reported by:jbboehr at gmail dot com
Summary:Segmentation fault with
MySQLi_Result::fetch_fields()
Status: Feedback
Type: Bug
Package:MySQLi related
Operating System: CentOS release 5.6 (Final)
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Mysql Server 5.1.56-log
Linked against libmysql
Previous Comments:
[2011-08-22 18:17:41] lgandras at gmail dot com
Hi,
sorry. We're not able to install till cpanel upgrades it's packages. This
usually takes a few weeks. I'm subscribed anyway and will update you as soon as
cpanel gets us a newer release.
[2011-08-22 14:32:39] ka...@php.net
Hi
Does this happen with PHP 5.3.7, what MySQL server version are you using and
what MySQL client library is PHP linked against (libmysql or mysqlnd)?
[2011-08-16 01:48:29] jbboehr at gmail dot com
PS Thanks for the gdb
[2011-08-16 01:48:02] jbboehr at gmail dot com
@lgandras For now, we're just using a work-around case for MySQLi, maybe it'll
help you:
if( $adapter instanceof Zend_Db_Adapter_Mysqli ) {
// Fixes MySQLI segfault in fetch_fields() with SHOW ENGINES
$connection = $adapter->getConnection();
$result = mysqli_query($connection, 'SHOW ENGINES');
if ( !$result instanceof MySQLi_STMT ){
return $this->_error('badAdapter');
}
$data = array();
while ( $row = $result->fetch_array() ){
$data[] = $row;
}
} else {
try {
$data = $adapter->query('SHOW ENGINES')->fetchAll();
} catch( Exception $e ) {
return $this->_error('badAdapter');
}
}
[2011-08-16 01:33:19] lgandras at gmail dot com
Hi,
Thank you so much. I was just posting my bug without a reproducible script
https://bugs.php.net/bug.php?id=55431. Here's your gdb =)
#0 0x0841f2e8 in add_property_string_ex (arg=0x907af64, key=0x87ad4cc
"catalog", key_len=8, str=0x31313230 ,
duplicate=1)
at /home/cpeasyapache/src/php-5.3.6/Zend/zend_API.c:1524
#1 0x081d7628 in php_add_field_properties (value=0x907af64, field=0x90fc6e0)
at /home/cpeasyapache/src/php-5.3.6/ext/mysqli/mysqli_api.c:1056
#2 0x081d79b7 in zif_mysqli_fetch_fields (ht=0, return_value=0x907ae80,
return_value_ptr=0x0, this_ptr=0x907a9e8, return_value_used=0)
at /home/cpeasyapache/src/php-5.3.6/ext/mysqli/mysqli_api.c:1114
#3 0x0844632f in zend_do_fcall_common_helper_SPEC (execute_data=0x90a6e50) at
/home/cpeasyapache/src/php-5.3.6/Zend/zend_vm_execute.h:316
#4 0x08446f6b in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x90a6e50)
at /home/cpeasyapache/src/php-5.3.6/Zend/zend_vm_execute.h:421
#5 0x084456fe in execute (op_array=0x90783f0) at
/home/cpeasyapache/src/php-5.3.6/Zend/zend_vm_execute.h:107
#6 0x08419b44 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/home/cpeasyapache/src/php-5.3.6/Zend/zend.c:1194
#7 0x083ad584 in php_execute_script (primary_file=0xbf8cbb04) at
/home/cpeasyapache/src/php-5.3.6/main/main.c:2268
#8 0x084e6f64 in main (argc=2, argv=0xbf8cbc64) at
/home/cpeasyapache/src/php-5.3.6/sapi/cli/php_cli.c:1193
I'm exactly in the same situation as you. I can't use PHP 5.3.6. This doesn't
seem to happen in PHP 5.3.5.
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
https://bugs.php.net/bug.php?id=55414
--
Edit this bug report at https://bugs.php.net/bug.php?id=55414&edit=1
Bug #55475 [Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1 ID: 55475 Updated by: col...@php.net Reported by:mads at gartneriet dot dk Summary:is_a() triggers autoloader Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.3.7 Assigned To:dmitry Block user comment: N Private report: N New Comment: What code? Do you have some example? Previous Comments: [2011-08-22 19:17:28] mads at gartneriet dot dk Maybe not a bug, but it is behaving different ind 5.3.7 than in the previous versions, which makes some of the code from PEAR that i use, give errors. [2011-08-22 18:36:59] s...@php.net This is not a bug. If first argument is a string, it is interpreted as a class name and autoloader is called for it. Actually, IIRC, one the reasons why is_a was un-deprecated is that it can work with strings. [2011-08-22 15:46:05] johan...@php.net is_a()'s first argument is documented to be an object. If called with a string, following the documentation, I would actually expect a "Warning: is_a() expects parameter 1 to be object, string given" and return NULL. That aside and looking at the actual behavior: Previously is_a() could be used to check whether the parameter is an object AND of a specific type in one go. This can't be done anymore. In $a = "test"; is_a($a, "foo"); test might be an existing class and might be of type foo. Now people have to do is_object() && is_a(). I don't like having such behavior change in bug fix versions as I don't like going back and forth which is annoying for documentation and confusing for users. I would love to keep it out of 5.3.8 to have that as low risk quick release for the hash issue. Which means a rollback to the old way is even harder to do. (two versions with the new behavior out) [2011-08-22 14:49:31] col...@php.net Well, we have 3 options here: 1) keep it like it is since 5.3.7 2) reverting it to how it worked before 5.3.7 3) change it even more to not use autoload, so that it neither works like <5.3.6 nor 5.3.7 Apparently through your proposed fix you're advocating for (3). If so, I can't see how it would improve the situation in any way. Personally, given that the BC change is minimal, and that we're only adding functionality, (1) seems fine. Correct code existing before 5.3.6 will work just fine anyway. [2011-08-22 14:44:18] ka...@php.net ... the behaviour I'm talking about is obvious the return value and the fact that the autoloader now is called. 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 https://bugs.php.net/bug.php?id=55475 -- Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55439 [Com]: crypt() returns only the salt for MD5
Edit report at https://bugs.php.net/bug.php?id=55439&edit=1 ID: 55439 Comment by: lolphp at mailinator dot com Reported by:jo at feuersee dot de Summary:crypt() returns only the salt for MD5 Status: Closed Type: Bug Package:*Encryption and hash functions Operating System: Linux PHP Version:5.3.7RC5 Assigned To:stas Block user comment: N Private report: N New Comment: http://i.imgur.com/oNHGZ.jpg Previous Comments: [2011-08-20 09:09:40] paj...@php.net Yes, we will release 5.3.7pl1 or 5.3.8 [2011-08-20 08:48:09] info at onlime dot ch thanks for fixing this (in my eyes) release critical bug. Are you going to release an official 5.3.7pl1 soon? I'm not able to deploy a SVN/snapshot release on our webservers. It simply doesn't look good. Our customers rely on stable PHP releases. I would very much appreciate a pl1 release. [2011-08-20 01:32:04] noel dot butler at ausics dot net Thanks stas, confirmed fixed in snapshot 201108200030 [2011-08-19 22:50:07] s...@php.net This bug has been fixed in SVN. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. fixed, thanks [2011-08-19 22:49:11] s...@php.net Automatic comment from SVN on behalf of stas Revision: http://svn.php.net/viewvc/?view=revision&revision=315218 Log: Unbreak crypt() (fix bug #55439) # If you want to remove static analyser messages, be my guest, # but please run unit tests after 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 https://bugs.php.net/bug.php?id=55439 -- Edit this bug report at https://bugs.php.net/bug.php?id=55439&edit=1
Bug #55348 [Com]: SoapServer (typemap related) "Error calling from_xml callback"
Edit report at https://bugs.php.net/bug.php?id=55348&edit=1 ID: 55348 Comment by: chris at cmbuckley dot co dot uk Reported by:sprotte at visionconnect dot de Summary:SoapServer (typemap related) "Error calling from_xml callback" Status: Open Type: Bug Package:SOAP related Operating System: openSUSE 11.4 PHP Version:5.3.7RC4 Block user comment: N Private report: N New Comment: Description: Reduced to smaller test script. Test script: http://starsquare.co.uk/code/php/bugs/55348.phps Expected result: ... SOAP-ENV:Server Conversion Fault ... Actual result: -- Fatal error: SOAP-ERROR: Encoding: Error calling from_xml callback Previous Comments: [2011-08-02 15:14:41] sprotte at visionconnect dot de Description: Throwing a SoapFault exception inside the from_xml callback function (when using the "typemap" feature with SoapServer) does not work as expected in some cases. I have created a small client/server application with one working example (type "date") and one not working example (type "myType"). In case of the "date" type the SoapFault exception is transformed into a matching SOAP-Response. The original message is available on the client side. In case of the "myType" type the thrown SoapFault exception is completely ignored and the SOAP-Response contains another error message. Test script: --- http://www.visionconnect.de/php_bugreports/soapserver_to_xml.tar.gz Expected result: Faultcode: 0001 Faultstring: Invalid date: 2011-15-15 Faultcode: 0002 Faultstring: Invalid type: foobar Actual result: -- Faultcode: 0001 Faultstring: Invalid date: 2011-15-15 Faultcode: SOAP-ENV:Server Faultstring: SOAP-ERROR: Encoding: Error calling from_xml callback -- Edit this bug report at https://bugs.php.net/bug.php?id=55348&edit=1
Bug #55441 [Fbk->Opn]: \Phar::createDefaultStub() does not handle its arguments
Edit report at https://bugs.php.net/bug.php?id=55441&edit=1
ID: 55441
User updated by:frederic dot hardy at mageekbox dot net
Reported by:frederic dot hardy at mageekbox dot net
Summary:\Phar::createDefaultStub() does not handle its
arguments
-Status: Feedback
+Status: Open
Type: Bug
Package:PHAR related
Operating System: MacOS X 10.6.8
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
';
$phar['web.php'] = '';
$phar->createDefaultStub('cli.php', 'web.php');
?>
# php createDefaultStub.phar
PHP Warning: include(phar:///path/to/createDefaultStub.phar/index.php): failed
to open stream: phar error: "index.php" is not a file in phar
"/path/to/createDefaultStub.phar" in /path/to/createDefaultStub.phar on line 9
Previous Comments:
[2011-08-22 14:13:29] ka...@php.net
By quickly skimming over the source it seems that in order for this function to
work both parameters must have a value. Have you tried that?
[2011-08-17 13:43:16] frederic dot hardy at mageekbox dot net
Description:
\Phar::createDefaultStub() takes two optional arguments.
With these arguments, the user can defined file in phar archive which will be
used
in stub.
However, these arguments seems to be not used by \Phar::createDefaultStub().
Test script:
---
';
$phar->createDefaultStub('stub.php');
Expected result:
This is the stub !
Actual result:
--
PHP Warning: include(phar:///path/to/my.phar/index.php): failed to open
stream:
phar error: "index.php" is not a file in phar "/path/to/my.phar" in
/path/to/my.phar on line 9
--
Edit this bug report at https://bugs.php.net/bug.php?id=55441&edit=1
Bug #55475 [Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1 ID: 55475 User updated by:mads at gartneriet dot dk Reported by:mads at gartneriet dot dk Summary:is_a() triggers autoloader Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.3.7 Assigned To:dmitry Block user comment: N Private report: N New Comment: Maybe not a bug, but it is behaving different ind 5.3.7 than in the previous versions, which makes some of the code from PEAR that i use, give errors. Previous Comments: [2011-08-22 18:36:59] s...@php.net This is not a bug. If first argument is a string, it is interpreted as a class name and autoloader is called for it. Actually, IIRC, one the reasons why is_a was un-deprecated is that it can work with strings. [2011-08-22 15:46:05] johan...@php.net is_a()'s first argument is documented to be an object. If called with a string, following the documentation, I would actually expect a "Warning: is_a() expects parameter 1 to be object, string given" and return NULL. That aside and looking at the actual behavior: Previously is_a() could be used to check whether the parameter is an object AND of a specific type in one go. This can't be done anymore. In $a = "test"; is_a($a, "foo"); test might be an existing class and might be of type foo. Now people have to do is_object() && is_a(). I don't like having such behavior change in bug fix versions as I don't like going back and forth which is annoying for documentation and confusing for users. I would love to keep it out of 5.3.8 to have that as low risk quick release for the hash issue. Which means a rollback to the old way is even harder to do. (two versions with the new behavior out) [2011-08-22 14:49:31] col...@php.net Well, we have 3 options here: 1) keep it like it is since 5.3.7 2) reverting it to how it worked before 5.3.7 3) change it even more to not use autoload, so that it neither works like <5.3.6 nor 5.3.7 Apparently through your proposed fix you're advocating for (3). If so, I can't see how it would improve the situation in any way. Personally, given that the BC change is minimal, and that we're only adding functionality, (1) seems fine. Correct code existing before 5.3.6 will work just fine anyway. [2011-08-22 14:44:18] ka...@php.net ... the behaviour I'm talking about is obvious the return value and the fact that the autoloader now is called. [2011-08-22 14:40:46] ka...@php.net I'm talking about the usual procedure we have about changing behaviour, a function suddenly returns the oppersite of what it used to in the middle of a stable series is very unlike to do, even for PHP. I knnow it went from not working to working, but I don't on the fact that such a commonly used function will change behaviour like that. What we should do is to make a big fat warning in the migration guide for 5.3.x -> 5.4.x about it, and in the manual. It would be the same if we changed substr() to be case insensitive in the middle of a release series, lets just not venture in such dark corners. 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 https://bugs.php.net/bug.php?id=55475 -- Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55475 [Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1 ID: 55475 Updated by: s...@php.net Reported by:mads at gartneriet dot dk Summary:is_a() triggers autoloader Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.3.7 Assigned To:dmitry Block user comment: N Private report: N New Comment: This is not a bug. If first argument is a string, it is interpreted as a class name and autoloader is called for it. Actually, IIRC, one the reasons why is_a was un-deprecated is that it can work with strings. Previous Comments: [2011-08-22 15:46:05] johan...@php.net is_a()'s first argument is documented to be an object. If called with a string, following the documentation, I would actually expect a "Warning: is_a() expects parameter 1 to be object, string given" and return NULL. That aside and looking at the actual behavior: Previously is_a() could be used to check whether the parameter is an object AND of a specific type in one go. This can't be done anymore. In $a = "test"; is_a($a, "foo"); test might be an existing class and might be of type foo. Now people have to do is_object() && is_a(). I don't like having such behavior change in bug fix versions as I don't like going back and forth which is annoying for documentation and confusing for users. I would love to keep it out of 5.3.8 to have that as low risk quick release for the hash issue. Which means a rollback to the old way is even harder to do. (two versions with the new behavior out) [2011-08-22 14:49:31] col...@php.net Well, we have 3 options here: 1) keep it like it is since 5.3.7 2) reverting it to how it worked before 5.3.7 3) change it even more to not use autoload, so that it neither works like <5.3.6 nor 5.3.7 Apparently through your proposed fix you're advocating for (3). If so, I can't see how it would improve the situation in any way. Personally, given that the BC change is minimal, and that we're only adding functionality, (1) seems fine. Correct code existing before 5.3.6 will work just fine anyway. [2011-08-22 14:44:18] ka...@php.net ... the behaviour I'm talking about is obvious the return value and the fact that the autoloader now is called. [2011-08-22 14:40:46] ka...@php.net I'm talking about the usual procedure we have about changing behaviour, a function suddenly returns the oppersite of what it used to in the middle of a stable series is very unlike to do, even for PHP. I knnow it went from not working to working, but I don't on the fact that such a commonly used function will change behaviour like that. What we should do is to make a big fat warning in the migration guide for 5.3.x -> 5.4.x about it, and in the manual. It would be the same if we changed substr() to be case insensitive in the middle of a release series, lets just not venture in such dark corners. [2011-08-22 14:27:31] col...@php.net But what BC break are you talking about exactly? It went from not-working (returning always false for strings as first argument) to working with autoload. 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 https://bugs.php.net/bug.php?id=55475 -- Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #51625 [Com]: php: threads.c:321: krb5int_key_register: Assertion `keynum >= 0 && keynum < K5
Edit report at https://bugs.php.net/bug.php?id=51625&edit=1 ID: 51625 Comment by: thinice at gmail dot com Reported by:Eduards dot Samersovs at inbox dot lv Summary:php: threads.c:321: krb5int_key_register: Assertion `keynum >= 0 && keynum < K5 Status: Assigned Type: Bug Package:OCI8 related Operating System: Ubuntu 9.10 PHP Version:5.3.2 Assigned To:sixd Block user comment: N Private report: N New Comment: Mike: Did you also run the make for imap2007e lib? It's a bit goofy, you have to specify a distro. Previous Comments: [2011-08-22 17:52:50] mike dot mackintosh at angrystatic dot com I have duplicated this currently on versions including 5.3.6 and on Debian Squeeze, CentOS6, and Ubuntu 11.1. I've done the following steps to reproduce the issue: unzip instantclient-basic-linux32-11.2.0.2.0.zip unzip instantclient-sdk-linux32-11.2.0.2.0.zip mv instantclient_11_2/sdk/ instantclient_11_2/ sudo mkdir /usr/local/oracle mv instantclient_11_2/ /usr/local/oracle/instantclient sudo mv instantclient_11_2/ /usr/local/oracle/instantclient cd /usr/local/oracle/instantclient/ sudo ln -s /usr/local/oracle/instantclient/libclntsh.so.11.1 libclntsh.so sudo ln -s /usr/local/oracle/instantclient/libocci.so.11.1 libocci.so.11.1 sudo ln -s /usr/local/oracle/instantclient/libocci.so.11.1 libocci.so sudo ln -s /usr/local/oracle/instantclient/*.so /usr/lib mkdir lib cd lib/ sudo ln -s /usr/local/oracle/instantclient/*.so /usr/local/oracle/instantclient/lib My configure string: ./configure '--prefix=/usr/local/php-5.3.6' '--enable-cli' '--disable-debug' '--disable-rpath' '--disable-static' '--with-pic' '--with-openssl=/usr' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--enable-ctype' '--with-curl' '--with-zlib-dir=/usr' '--with-xsl' '--enable-exif' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr' '--with-gettext' '--with-iconv' '--with-imap' '--with-kerberos=/usr' '--with-imap-ssl=/usr' '--enable-mbstring' '--with-mcrypt' '--with-mhash' '--with-mime-magic' '--with-mysql=/usr/local/mysql-5.1.57' '--with-pcre-regex=/usr' '--with-pspell=/usr' '--enable-sockets' '--enable-wddx' '--with-xmlrpc' '--with-zlib=/usr' '--with-pear' '--with-layout=GNU' '--with-ldap' '--enable-pdo' '--enable-soap' '--with-apxs2=/usr/local/apache-2.2.19/bin/apxs' '--enable-pcntl' '--enable-mailparse' '--enable-zip' '--with-zip=/usr' '--with-bz2=/usr' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/usr/local/php-5.3.6/etc' '--with-pdo-mysql=/usr/local/mysql-5.1.57' '--with-openssl=/usr' '--enable-zip' '--with-snmp' '--with-mysqli=/usr/local/mysql-5.1.57/bin/mysql_config' '--with-phar' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--with-tidy' --with-oci8=instantclient,/usr/local/oracle/instantclient --with-pdo-oci=instantclient,/usr/local/oracle/instantclient,11.2.0.2 make Ran into an issue where PHP tried to compile LDAP from the Oracle SDK, removed sdk/ldap.h re-ran the above, and received the error: php: threads.c:321: krb5int_key_register: Assertion `keynum >= 0 && keynum < K5_KEY_MAX' failed. Removed the --with-kerberos option,and received: configure: error: This c-client library is built with Kerberos support. Add --with-kerberos to your configure line. Check config.log for details. Even with libc-client2007e for imap, i continue to receive the above. I only receive an issue when compiling in oci support using the 11.x family Removing all IMAP from the configure fixed the issue. [2011-02-21 05:21:13] thinice at gmail dot com I resolved the issue by manually downloading libc-client2007e, Updating '--with-imap' config str to point to the libc-client2007e dir, (--with-imap=/path/to/libc-client2007e --with-imap-ssl). This allowed me to drop the '--with-kerberos' directive and elminating the error. [2011-02-21 01:38:02] thinice at gmail dot com Using: ./configure --prefix=/usr --with-config-file-path=/etc/php5 --with-config-file-scan-dir=/etc/php5/apache2/conf.d --with-exec-dir=/usr/lib/php5/libexec --mandir=/usr/share/man --enable-cli --enable-sysvsem --enable-mbstring --enable-sockets --enable-soap --with-apxs2=/usr/bin/apxs2 --with-iconv --with-curl --with-zlib --with-openssl --with-ldap --with-mysql --with-mysqli --with-tidy --with-xmlrpc --with-oci8=instantclient,/opt/oracle/instantclient_11_1 --with-gd --enable-gd-native-ttf --with-jpeg-dir=/usr --with-xpm-dir=/usr/X11R6 --with-png-dir=/usr --with-freetype-dir=/usr --with-t1lib=/usr --with-mssql --enable-soap --with-imap --with-imap-ssl --with-kerberos --with-xs
Bug #55390 [Fbk]: win + apache2 + php crash
Edit report at https://bugs.php.net/bug.php?id=55390&edit=1 ID: 55390 Updated by: paj...@php.net Reported by:giorgio dot liscio at email dot it Summary:win + apache2 + php crash Status: Feedback Type: Bug Package:*General Issues Operating System: windows 7 x64 ultimate PHP Version:5.4SVN-2011-08-10 (snap) Block user comment: N Private report: N New Comment: Yes, it is enough and if you can provide a script to reproduce it, even better. Previous Comments: [2011-08-22 18:02:25] giorgio dot liscio at email dot it can I use the "without compiler method" to provide a backtrace of php as apache module? I don't think it is related to apache but i will probably need a webserver to run the evil script [2011-08-22 15:19:57] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. . [2011-08-22 14:46:34] ka...@php.net Do you have any extensions like Xdebug, APC or other extensions that may hook into the include construct? [2011-08-10 06:24:23] giorgio dot liscio at email dot it Description: i can't identify the problem yet but php simply crash when i include a file the included file is executed totally but at the end something goes wrong (it is not a simple include, i'm trying to identify the code that crashes apache) according to windows php snaps: Thursday, July 28, 2011 2:33 AM r313803 <-- this works Tuesday, August 02, 2011 11:52 AM r314086 <-- this crashes ... and crashes with latest snap too event name: APPCRASH app name: httpd.exe app vers: 2.2.17.0 timestamp: 4cbc89f4 err module: MSVCR90.dll module version: 9.0.30729.6161 module timestamp: 4dace5b9 exception code: c005 exception offset: 0003ae7a os version: 6.1.7601.2.1.0.256.1 locale: 1040 additional info1: 0a9e additional info2: 0a9e372d3b4ad19135b953a78882e789 additional info3: 0a9e additional info4: 0a9e372d3b4ad19135b953a78882e789 not sure if it is related because it is not logged at every page load, but sometimes apache logs "zend_mm_heap corrupted" thanks in advance -- Edit this bug report at https://bugs.php.net/bug.php?id=55390&edit=1
Bug #55414 [Com]: Segmentation fault with MySQLi_Result::fetch_fields()
Edit report at https://bugs.php.net/bug.php?id=55414&edit=1
ID: 55414
Comment by: lgandras at gmail dot com
Reported by:jbboehr at gmail dot com
Summary:Segmentation fault with
MySQLi_Result::fetch_fields()
Status: Feedback
Type: Bug
Package:MySQLi related
Operating System: CentOS release 5.6 (Final)
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Hi,
sorry. We're not able to install till cpanel upgrades it's packages. This
usually takes a few weeks. I'm subscribed anyway and will update you as soon as
cpanel gets us a newer release.
Previous Comments:
[2011-08-22 14:32:39] ka...@php.net
Hi
Does this happen with PHP 5.3.7, what MySQL server version are you using and
what MySQL client library is PHP linked against (libmysql or mysqlnd)?
[2011-08-16 01:48:29] jbboehr at gmail dot com
PS Thanks for the gdb
[2011-08-16 01:48:02] jbboehr at gmail dot com
@lgandras For now, we're just using a work-around case for MySQLi, maybe it'll
help you:
if( $adapter instanceof Zend_Db_Adapter_Mysqli ) {
// Fixes MySQLI segfault in fetch_fields() with SHOW ENGINES
$connection = $adapter->getConnection();
$result = mysqli_query($connection, 'SHOW ENGINES');
if ( !$result instanceof MySQLi_STMT ){
return $this->_error('badAdapter');
}
$data = array();
while ( $row = $result->fetch_array() ){
$data[] = $row;
}
} else {
try {
$data = $adapter->query('SHOW ENGINES')->fetchAll();
} catch( Exception $e ) {
return $this->_error('badAdapter');
}
}
[2011-08-16 01:33:19] lgandras at gmail dot com
Hi,
Thank you so much. I was just posting my bug without a reproducible script
https://bugs.php.net/bug.php?id=55431. Here's your gdb =)
#0 0x0841f2e8 in add_property_string_ex (arg=0x907af64, key=0x87ad4cc
"catalog", key_len=8, str=0x31313230 ,
duplicate=1)
at /home/cpeasyapache/src/php-5.3.6/Zend/zend_API.c:1524
#1 0x081d7628 in php_add_field_properties (value=0x907af64, field=0x90fc6e0)
at /home/cpeasyapache/src/php-5.3.6/ext/mysqli/mysqli_api.c:1056
#2 0x081d79b7 in zif_mysqli_fetch_fields (ht=0, return_value=0x907ae80,
return_value_ptr=0x0, this_ptr=0x907a9e8, return_value_used=0)
at /home/cpeasyapache/src/php-5.3.6/ext/mysqli/mysqli_api.c:1114
#3 0x0844632f in zend_do_fcall_common_helper_SPEC (execute_data=0x90a6e50) at
/home/cpeasyapache/src/php-5.3.6/Zend/zend_vm_execute.h:316
#4 0x08446f6b in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x90a6e50)
at /home/cpeasyapache/src/php-5.3.6/Zend/zend_vm_execute.h:421
#5 0x084456fe in execute (op_array=0x90783f0) at
/home/cpeasyapache/src/php-5.3.6/Zend/zend_vm_execute.h:107
#6 0x08419b44 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/home/cpeasyapache/src/php-5.3.6/Zend/zend.c:1194
#7 0x083ad584 in php_execute_script (primary_file=0xbf8cbb04) at
/home/cpeasyapache/src/php-5.3.6/main/main.c:2268
#8 0x084e6f64 in main (argc=2, argv=0xbf8cbc64) at
/home/cpeasyapache/src/php-5.3.6/sapi/cli/php_cli.c:1193
I'm exactly in the same situation as you. I can't use PHP 5.3.6. This doesn't
seem to happen in PHP 5.3.5.
[2011-08-13 01:00:56] jbboehr at gmail dot com
Ok, so gdb was not installed on the server (sigh), however here's part of the
strace, maybe that will help.
connect(4, {sa_family=AF_FILE, path="/var/lib/mysql/mysql.sock"...}, 110) = 0
setsockopt(4, SOL_SOCKET, SO_RCVTIMEO, "\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0",
16) = 0
setsockopt(4, SOL_SOCKET, SO_SNDTIMEO, "\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0",
16) = 0
setsockopt(4, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation not
supported)
setsockopt(4, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
read(4, ">\0\0\0\n5.0.92-community\0\350\352^\0@Dp,%u"..., 16384) = 66
stat("/usr/share/mysql/charsets/Index.xml", {st_mode=S_IFREG|0755,
st_size=18173, ...}) = 0
open("/usr/share/mysql/charsets/Index.xml", O_RDONLY) = 5
read(5, "https://bugs.php.net/bug.php?id=55414
--
Edit this bug report at https://bugs.php.net/bug.php?id=55414&edit=1
Bug #55390 [Com]: win + apache2 + php crash
Edit report at https://bugs.php.net/bug.php?id=55390&edit=1 ID: 55390 Comment by: giorgio dot liscio at email dot it Reported by:giorgio dot liscio at email dot it Summary:win + apache2 + php crash Status: Feedback Type: Bug Package:*General Issues Operating System: windows 7 x64 ultimate PHP Version:5.4SVN-2011-08-10 (snap) Block user comment: N Private report: N New Comment: can I use the "without compiler method" to provide a backtrace of php as apache module? I don't think it is related to apache but i will probably need a webserver to run the evil script Previous Comments: [2011-08-22 15:19:57] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. . [2011-08-22 14:46:34] ka...@php.net Do you have any extensions like Xdebug, APC or other extensions that may hook into the include construct? [2011-08-10 06:24:23] giorgio dot liscio at email dot it Description: i can't identify the problem yet but php simply crash when i include a file the included file is executed totally but at the end something goes wrong (it is not a simple include, i'm trying to identify the code that crashes apache) according to windows php snaps: Thursday, July 28, 2011 2:33 AM r313803 <-- this works Tuesday, August 02, 2011 11:52 AM r314086 <-- this crashes ... and crashes with latest snap too event name: APPCRASH app name: httpd.exe app vers: 2.2.17.0 timestamp: 4cbc89f4 err module: MSVCR90.dll module version: 9.0.30729.6161 module timestamp: 4dace5b9 exception code: c005 exception offset: 0003ae7a os version: 6.1.7601.2.1.0.256.1 locale: 1040 additional info1: 0a9e additional info2: 0a9e372d3b4ad19135b953a78882e789 additional info3: 0a9e additional info4: 0a9e372d3b4ad19135b953a78882e789 not sure if it is related because it is not logged at every page load, but sometimes apache logs "zend_mm_heap corrupted" thanks in advance -- Edit this bug report at https://bugs.php.net/bug.php?id=55390&edit=1
Bug #51625 [Com]: php: threads.c:321: krb5int_key_register: Assertion `keynum >= 0 && keynum < K5
Edit report at https://bugs.php.net/bug.php?id=51625&edit=1 ID: 51625 Comment by: mike dot mackintosh at angrystatic dot com Reported by:Eduards dot Samersovs at inbox dot lv Summary:php: threads.c:321: krb5int_key_register: Assertion `keynum >= 0 && keynum < K5 Status: Assigned Type: Bug Package:OCI8 related Operating System: Ubuntu 9.10 PHP Version:5.3.2 Assigned To:sixd Block user comment: N Private report: N New Comment: I have duplicated this currently on versions including 5.3.6 and on Debian Squeeze, CentOS6, and Ubuntu 11.1. I've done the following steps to reproduce the issue: unzip instantclient-basic-linux32-11.2.0.2.0.zip unzip instantclient-sdk-linux32-11.2.0.2.0.zip mv instantclient_11_2/sdk/ instantclient_11_2/ sudo mkdir /usr/local/oracle mv instantclient_11_2/ /usr/local/oracle/instantclient sudo mv instantclient_11_2/ /usr/local/oracle/instantclient cd /usr/local/oracle/instantclient/ sudo ln -s /usr/local/oracle/instantclient/libclntsh.so.11.1 libclntsh.so sudo ln -s /usr/local/oracle/instantclient/libocci.so.11.1 libocci.so.11.1 sudo ln -s /usr/local/oracle/instantclient/libocci.so.11.1 libocci.so sudo ln -s /usr/local/oracle/instantclient/*.so /usr/lib mkdir lib cd lib/ sudo ln -s /usr/local/oracle/instantclient/*.so /usr/local/oracle/instantclient/lib My configure string: ./configure '--prefix=/usr/local/php-5.3.6' '--enable-cli' '--disable-debug' '--disable-rpath' '--disable-static' '--with-pic' '--with-openssl=/usr' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--enable-ctype' '--with-curl' '--with-zlib-dir=/usr' '--with-xsl' '--enable-exif' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr' '--with-gettext' '--with-iconv' '--with-imap' '--with-kerberos=/usr' '--with-imap-ssl=/usr' '--enable-mbstring' '--with-mcrypt' '--with-mhash' '--with-mime-magic' '--with-mysql=/usr/local/mysql-5.1.57' '--with-pcre-regex=/usr' '--with-pspell=/usr' '--enable-sockets' '--enable-wddx' '--with-xmlrpc' '--with-zlib=/usr' '--with-pear' '--with-layout=GNU' '--with-ldap' '--enable-pdo' '--enable-soap' '--with-apxs2=/usr/local/apache-2.2.19/bin/apxs' '--enable-pcntl' '--enable-mailparse' '--enable-zip' '--with-zip=/usr' '--with-bz2=/usr' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/usr/local/php-5.3.6/etc' '--with-pdo-mysql=/usr/local/mysql-5.1.57' '--with-openssl=/usr' '--enable-zip' '--with-snmp' '--with-mysqli=/usr/local/mysql-5.1.57/bin/mysql_config' '--with-phar' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--with-tidy' --with-oci8=instantclient,/usr/local/oracle/instantclient --with-pdo-oci=instantclient,/usr/local/oracle/instantclient,11.2.0.2 make Ran into an issue where PHP tried to compile LDAP from the Oracle SDK, removed sdk/ldap.h re-ran the above, and received the error: php: threads.c:321: krb5int_key_register: Assertion `keynum >= 0 && keynum < K5_KEY_MAX' failed. Removed the --with-kerberos option,and received: configure: error: This c-client library is built with Kerberos support. Add --with-kerberos to your configure line. Check config.log for details. Even with libc-client2007e for imap, i continue to receive the above. I only receive an issue when compiling in oci support using the 11.x family Removing all IMAP from the configure fixed the issue. Previous Comments: [2011-02-21 05:21:13] thinice at gmail dot com I resolved the issue by manually downloading libc-client2007e, Updating '--with-imap' config str to point to the libc-client2007e dir, (--with-imap=/path/to/libc-client2007e --with-imap-ssl). This allowed me to drop the '--with-kerberos' directive and elminating the error. [2011-02-21 01:38:02] thinice at gmail dot com Using: ./configure --prefix=/usr --with-config-file-path=/etc/php5 --with-config-file-scan-dir=/etc/php5/apache2/conf.d --with-exec-dir=/usr/lib/php5/libexec --mandir=/usr/share/man --enable-cli --enable-sysvsem --enable-mbstring --enable-sockets --enable-soap --with-apxs2=/usr/bin/apxs2 --with-iconv --with-curl --with-zlib --with-openssl --with-ldap --with-mysql --with-mysqli --with-tidy --with-xmlrpc --with-oci8=instantclient,/opt/oracle/instantclient_11_1 --with-gd --enable-gd-native-ttf --with-jpeg-dir=/usr --with-xpm-dir=/usr/X11R6 --with-png-dir=/usr --with-freetype-dir=/usr --with-t1lib=/usr --with-mssql --enable-soap --with-imap --with-imap-ssl --with-kerberos --with-xsl --with-pspell --disable-phar Console snip: -- Build complete. Don't forget to run 'make test'. mhd-www:~/php-5.3.5# make install Installing PHP SAPI module: apache2handler /usr/share/apache2/build/ins
Bug #55479 [Opn]: ext/pcntl/tests failures
Edit report at https://bugs.php.net/bug.php?id=55479&edit=1 ID: 55479 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:ext/pcntl/tests failures Status: Open Type: Bug Package:PCNTL related PHP Version:5.4.0alpha3 Block user comment: N Private report: N New Comment: proposed patch: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/php/bug-test-pcntl- 55479.patch Previous Comments: [2011-08-22 17:03:56] glen at delfi dot ee Description: there are ext/pcntl/tests failures due it using $TEST_PHP_EXECUTABLE which uses installed php config, but tests should be self-contained and use config extensions from BUILT codebase. for example if i have installed php 5.3 and i try to run tests on 5.4 i get errors: + /usr/bin/make -j16 test EXTENSION_DIR=modules PHP_TEST_SHARED_SYSTEM_EXTENSIONS= RUN_TESTS_SETTINGS=-q ext/pcntl/tests/pcntl_exec_2.phpt --show-out Build complete. Don't forget to run 'make test'. = PHP : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.4.0alpha3 ZEND_VERSION: 2.4.0 PHP_OS : Linux - Linux carme-pld-i686 3.0.0_nogrsecurity-0.3 #1 SMP Wed Jul 27 21:17:15 CEST 2011 i686 INI actual : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3/tmp-php.ini More .INIs : CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/1 [ext/pcntl/tests/pcntl_exec_2.phpt] OUT ok PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/pcre.so' - /usr/lib/php/pcre.so: undefined symbol: php_addslashes_ex in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/spl.so' - /usr/lib/php/spl.so: undefined symbol: php_pcre_replace_impl in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/session.so' - /usr/lib/php/session.so: undefined symbol: php_get_output_start_filename in Unknown on line 0 PHP Warning: PHP Startup: bcmath: Unable to initialize module Module compiled with module API=20090626 PHPcompiled with module API=20100525 These options need to match in Unknown on line 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=55479&edit=1
[PHP-BUG] Bug #55479 [NEW]: ext/pcntl/tests failures
From: Operating system: PHP version: 5.4.0alpha3 Package: PCNTL related Bug Type: Bug Bug description:ext/pcntl/tests failures Description: there are ext/pcntl/tests failures due it using $TEST_PHP_EXECUTABLE which uses installed php config, but tests should be self-contained and use config extensions from BUILT codebase. for example if i have installed php 5.3 and i try to run tests on 5.4 i get errors: + /usr/bin/make -j16 test EXTENSION_DIR=modules PHP_TEST_SHARED_SYSTEM_EXTENSIONS= RUN_TESTS_SETTINGS=-q ext/pcntl/tests/pcntl_exec_2.phpt --show-out Build complete. Don't forget to run 'make test'. = PHP : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.4.0alpha3 ZEND_VERSION: 2.4.0 PHP_OS : Linux - Linux carme-pld-i686 3.0.0_nogrsecurity-0.3 #1 SMP Wed Jul 27 21:17:15 CEST 2011 i686 INI actual : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3/tmp-php.ini More .INIs : CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/1 [ext/pcntl/tests/pcntl_exec_2.phpt] OUT ok PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/pcre.so' - /usr/lib/php/pcre.so: undefined symbol: php_addslashes_ex in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/spl.so' - /usr/lib/php/spl.so: undefined symbol: php_pcre_replace_impl in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/session.so' - /usr/lib/php/session.so: undefined symbol: php_get_output_start_filename in Unknown on line 0 PHP Warning: PHP Startup: bcmath: Unable to initialize module Module compiled with module API=20090626 PHPcompiled with module API=20100525 These options need to match in Unknown on line 0 -- Edit bug report at https://bugs.php.net/bug.php?id=55479&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55479&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55479&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55479&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55479&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55479&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55479&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55479&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55479&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55479&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55479&r=support Expected behavior: https://bugs.php.net/fix.php?id=55479&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55479&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55479&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55479&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55479&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55479&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55479&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55479&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55479&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55479&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55479&r=mysqlcfg
[PHP-BUG] Bug #55478 [NEW]: FILTER_VALIDATE_EMAIL fails with valid addresses containing "--" twice
From: ch
Operating system: any
PHP version: 5.4.0alpha3
Package: Filter related
Bug Type: Bug
Bug description:FILTER_VALIDATE_EMAIL fails with valid addresses containing
"--" twice
Description:
The FILTER_VALIDATE_EMAIL check fails with valid adresses that contain "--"
twice because they have e.g. a German Umlaut ("ä") after a dash ("-").
The following examples can be verified using the converter tool on the
DeNIC page at
http://www.denic.de/domains/internationalized-domain-names/idn-konvertierung.html
IDN: example-ä.de
ACE-String: xn--example--7za.de
Test script:
---
--TEST--
Bug #X (FILTER_VALIDATE_EMAIL fails with valid addresses containing
"--" twice)
--FILE--
--EXPECTF--
%unicode|string%(21) "t...@xn--example--7za.de"
Expected result:
"t...@xn--example--7za.de"
Actual result:
--
bool(false)
$ TEST_PHP_EXECUTABLE=/home/chammers/workspace/php-src-5.4/sX.phpt /php
./run-tests.php ext/filter/tests/bugX
=
PHP : /home/chammers/workspace/php-src-5.4/sapi/cli/php
PHP_SAPI: cli
PHP_VERSION : 5.4.0beta1-dev
ZEND_VERSION: 2.4.0
PHP_OS : Linux - Linux sys-251 2.6.38-bpo.2-686 #1 SMP Tue Jun 14
11:43:18 UTC 2011 i686
INI actual : /home/chammers/workspace/php5/php5-5.3.3
More .INIs :
CWD : /home/chammers/workspace/php5/php5-5.3.3
Extra dirs :
VALGRIND: Not used
=
Running selected tests.
FAIL Bug #X (FILTER_VALIDATE_EMAIL fails with valid addresses
containing "--" twice) [ext/filter/tests/bugX.phpt]
--
Edit bug report at https://bugs.php.net/bug.php?id=55478&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55478&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55478&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55478&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55478&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55478&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55478&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55478&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55478&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55478&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55478&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55478&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55478&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55478&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55478&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55478&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55478&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55478&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55478&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55478&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55478&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55478&r=mysqlcfg
Bug #55475 [Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1 ID: 55475 Updated by: johan...@php.net Reported by:mads at gartneriet dot dk Summary:is_a() triggers autoloader Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.3.7 Assigned To:dmitry Block user comment: N Private report: N New Comment: is_a()'s first argument is documented to be an object. If called with a string, following the documentation, I would actually expect a "Warning: is_a() expects parameter 1 to be object, string given" and return NULL. That aside and looking at the actual behavior: Previously is_a() could be used to check whether the parameter is an object AND of a specific type in one go. This can't be done anymore. In $a = "test"; is_a($a, "foo"); test might be an existing class and might be of type foo. Now people have to do is_object() && is_a(). I don't like having such behavior change in bug fix versions as I don't like going back and forth which is annoying for documentation and confusing for users. I would love to keep it out of 5.3.8 to have that as low risk quick release for the hash issue. Which means a rollback to the old way is even harder to do. (two versions with the new behavior out) Previous Comments: [2011-08-22 14:49:31] col...@php.net Well, we have 3 options here: 1) keep it like it is since 5.3.7 2) reverting it to how it worked before 5.3.7 3) change it even more to not use autoload, so that it neither works like <5.3.6 nor 5.3.7 Apparently through your proposed fix you're advocating for (3). If so, I can't see how it would improve the situation in any way. Personally, given that the BC change is minimal, and that we're only adding functionality, (1) seems fine. Correct code existing before 5.3.6 will work just fine anyway. [2011-08-22 14:44:18] ka...@php.net ... the behaviour I'm talking about is obvious the return value and the fact that the autoloader now is called. [2011-08-22 14:40:46] ka...@php.net I'm talking about the usual procedure we have about changing behaviour, a function suddenly returns the oppersite of what it used to in the middle of a stable series is very unlike to do, even for PHP. I knnow it went from not working to working, but I don't on the fact that such a commonly used function will change behaviour like that. What we should do is to make a big fat warning in the migration guide for 5.3.x -> 5.4.x about it, and in the manual. It would be the same if we changed substr() to be case insensitive in the middle of a release series, lets just not venture in such dark corners. [2011-08-22 14:27:31] col...@php.net But what BC break are you talking about exactly? It went from not-working (returning always false for strings as first argument) to working with autoload. [2011-08-22 13:41:16] ka...@php.net I'm not arguing that the new behaviour is wrong, I believe it is the desired too but I don't agree to break BC in the middle of a stable release series nor as much as I would like to myself to achieve the right behaviour. 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 https://bugs.php.net/bug.php?id=55475 -- Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55477 [Com]: crypt() returns inconsistent hashes for non-ASCII characters
Edit report at https://bugs.php.net/bug.php?id=55477&edit=1 ID: 55477 Comment by: solar at openwall dot com Reported by:christian at pingdom dot com Summary:crypt() returns inconsistent hashes for non-ASCII characters Status: Bogus Type: Bug Package:*Encryption and hash functions Operating System: Linux PHP Version:5.3.7 Block user comment: N Private report: N New Comment: Oops, I did not realize this interface would use . Somehow the preview does not. I think it's my first time posting a comment to a PHP bug. Let me try again, with line wrapping at 79 for hopefully easier reading: This is definitely the expected behavior, but saying that $2x$ should be used for non-ASCII is not entirely correct (and is a dangerous thing to say). If it were this simple, we'd do it in PHP itself, but we had good reasons not to. More specifically: The change as implemented in PHP 5.3.7+ favors security and correctness over backwards compatibility, but it also lets users (admins of PHP app installs) use the new $2x$ prefix on existing hashes to preserve backwards compatibility for those and incur the associated security risk until all such passwords are changed (using $2a$ or $2y$ for newly changed passwords). In versions of PHP older than 5.3.7, $2a$ inadvertently resulted in system-specific behavior for passwords with non-ASCII characters in them. On some installs (mostly on PowerPC and ARM, as well as sometimes on *BSD's and Solaris regardless of CPU architecture), they were processed correctly. On most installs (most Linux, many others), they were processed incorrectly most of the time (but not always), and moreover in a way where security was weakened. In PHP 5.3.7, $2a$ results in almost the correct behavior, but with an additional countermeasure against security-weakened old hashes mentioned above. $2x$ results in the buggy behavior, so if old hashes are known to be of the buggy type, this may be used on them to keep them working, accepting the associated security risk. $2y$ results in perfectly correct behavior (without the countermeasure), so it may be used (if desired) when hashing newly set passwords. For practical purposes, it does not really matter if you use $2a$ or $2y$ for newly set passwords, as the countermeasure is only triggered on some obscure passwords (not even valid UTF-8) that are unlikely to be seen outside of a deliberate attack (trying to match hashes produced by buggy pre-5.3.7 code). BTW, PHP 5.3.7+ has been updated to crypt_blowfish 1.2, not the intermediate 1.1 release referenced in the previous comment. The differences between 1.1 and 1.2 include introduction of the countermeasure for $2a$ mentioned above and the $2y$ prefix. Summary: for passwords without characters with the 8th bit set, there's no issue, all three prefixes work exactly the same. For occasional passwords with characters with the 8th bit set, if the app prefers security and correctness over backwards compatibility, no action is needed - just upgrade to new PHP and use its new behavior (with $2a$). However, if an app install admin truly prefers backwards compatibility over security, and the problem is seen on the specific install (which is not always the case because not all platforms/builds were affected), then $2a$ in existing hashes in the database may be changed to $2x$. Alternatively, a similar thing may be achieved by changing $2a$ to $2x$ in PHP app code after database queries, and using $2y$ on newly set passwords (such that the app's automatic change to $2x$ on queries is not triggered for them). Previous Comments: [2011-08-22 15:21:31] solar at openwall dot com This is definitely the expected behavior, but saying that $2x$ should be used for non-ASCII is not entirely correct (and is a dangerous thing to say). If it were this simple, we'd do it in PHP itself, but we had good reasons not to. More specifically: The change as implemented in PHP 5.3.7+ favors security and correctness over backwards compatibility, but it also lets users (admins of PHP app installs) use the new $2x$ prefix on existing hashes to preserve backwards compatibility for those and incur the associated security risk until all such passwords are changed (using $2a$ or $2y$ for newly changed passwords). In versions of PHP older than 5.3.7, $2a$ inadvertently resulted in system-specific behavior for passwords with non-ASCII characters in them. On some installs (mostly on PowerPC and ARM, as well as sometimes on *BSD's and Solaris regardless of CPU architecture), they were processed correctly. On most installs (most Linux, many others), they were processed incorrectly most of the time (but not always), and moreover in a way where security was weakened. In PHP 5.3.7, $2a$ results in almost the correct behavior,
Bug #55477 [Com]: crypt() returns inconsistent hashes for non-ASCII characters
Edit report at https://bugs.php.net/bug.php?id=55477&edit=1
ID: 55477
Comment by: solar at openwall dot com
Reported by:christian at pingdom dot com
Summary:crypt() returns inconsistent hashes for non-ASCII
characters
Status: Bogus
Type: Bug
Package:*Encryption and hash functions
Operating System: Linux
PHP Version:5.3.7
Block user comment: N
Private report: N
New Comment:
This is definitely the expected behavior, but saying that $2x$ should be used
for non-ASCII is not entirely correct (and is a dangerous thing to say). If it
were this simple, we'd do it in PHP itself, but we had good reasons not to.
More specifically:
The change as implemented in PHP 5.3.7+ favors security and correctness over
backwards compatibility, but it also lets users (admins of PHP app installs)
use the new $2x$ prefix on existing hashes to preserve backwards compatibility
for those and incur the associated security risk until all such passwords are
changed (using $2a$ or $2y$ for newly changed passwords).
In versions of PHP older than 5.3.7, $2a$ inadvertently resulted in
system-specific behavior for passwords with non-ASCII characters in them. On
some installs (mostly on PowerPC and ARM, as well as sometimes on *BSD's and
Solaris regardless of CPU architecture), they were processed correctly. On
most installs (most Linux, many others), they were processed incorrectly most
of the time (but not always), and moreover in a way where security was weakened.
In PHP 5.3.7, $2a$ results in almost the correct behavior, but with an
additional countermeasure against security-weakened old hashes mentioned above.
$2x$ results in the buggy behavior, so if old hashes are known to be of the
buggy type, this may be used on them to keep them working, accepting the
associated security risk.
$2y$ results in perfectly correct behavior (without the countermeasure), so it
may be used (if desired) when hashing newly set passwords. For practical
purposes, it does not really matter if you use $2a$ or $2y$ for newly set
passwords, as the countermeasure is only triggered on some obscure passwords
(not even valid UTF-8) that are unlikely to be seen outside of a deliberate
attack (trying to match hashes produced by buggy pre-5.3.7 code).
BTW, PHP 5.3.7+ has been updated to crypt_blowfish 1.2, not the intermediate
1.1 release referenced in the previous comment. The differences between 1.1
and 1.2 include introduction of the countermeasure for $2a$ mentioned above and
the $2y$ prefix.
Summary: for passwords without characters with the 8th bit set, there's no
issue, all three prefixes work exactly the same. For occasional passwords with
characters with the 8th bit set, if the app prefers security and correctness
over backwards compatibility, no action is needed - just upgrade to new PHP and
use its new behavior (with $2a$). However, if an app install admin truly
prefers backwards compatibility over security, and the problem is seen on the
specific install (which is not always the case because not all platforms/builds
were affected), then $2a$ in existing hashes in the database may be changed to
$2x$. Alternatively, a similar thing may be achieved by changing $2a$ to $2x$
in PHP app code after database queries, and using $2y$ on newly set passwords
(such that the app's automatic change to $2x$ on queries is not triggered for
them).
Previous Comments:
[2011-08-22 13:29:04] bj...@php.net
This is expected, see http://www.openwall.com/lists/announce/2011/06/21/1
You need to use $2x$ for non-ascii, sorry :(
[2011-08-22 12:47:41] christian at pingdom dot com
Description:
Hashes generated with crypt() (using Blowfish) on PHP 5.3.5 or 5.3.3 cannot be
validated on 5.3.7, if the hashed strings contain non-ASCII characters. The
reverse is also true, if the hashes were generated on 5.3.7, they cannot be
validated on 5.3.3 or 5.3.5.
Test script:
---
$passwords = array(
// these hashes were generated on PHP 5.3.5-1ubuntu7.2 with Suhosin-Patch
(cli) (built: May 2 2011 23:00:17)
'brownfox' =>
'$2a$07$usesomesillystringforeD/hyr5e1bWX2PzwckMuCRNQMTrQNr72',
'Boxkämpfer' =>
'$2a$07$usesomesillystringfore36pVDWFz65CbxoLgSgVURqHWU4yEqye',
'ÑаÑÑлива' =>
'$2a$07$usesomesillystringforeoM7K1pyDjeAG1F42k34MP.tbiMnNcy.',
'Põdur' => '$2a$07$usesomesillystringfore1iPxMN9wh4Cr2oVR6nmdILWylX9D0iO',
);
foreach ($passwords as $password => $hash)
{
$computedHash = crypt($password, $hash);
if ($computedHash == $hash)
{
echo "hash OK\n";
}
else
{
echo "hash FAIL ($hash != $computedHash)\n";
}
}
Expected result:
hash OK
hash OK
hash OK
hash OK
Bug #55390 [Fbk]: win + apache2 + php crash
Edit report at https://bugs.php.net/bug.php?id=55390&edit=1 ID: 55390 Updated by: paj...@php.net Reported by:giorgio dot liscio at email dot it Summary:win + apache2 + php crash Status: Feedback Type: Bug Package:*General Issues Operating System: windows 7 x64 ultimate PHP Version:5.4SVN-2011-08-10 (snap) Block user comment: N Private report: N New Comment: 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. . Previous Comments: [2011-08-22 14:46:34] ka...@php.net Do you have any extensions like Xdebug, APC or other extensions that may hook into the include construct? [2011-08-10 06:24:23] giorgio dot liscio at email dot it Description: i can't identify the problem yet but php simply crash when i include a file the included file is executed totally but at the end something goes wrong (it is not a simple include, i'm trying to identify the code that crashes apache) according to windows php snaps: Thursday, July 28, 2011 2:33 AM r313803 <-- this works Tuesday, August 02, 2011 11:52 AM r314086 <-- this crashes ... and crashes with latest snap too event name: APPCRASH app name: httpd.exe app vers: 2.2.17.0 timestamp: 4cbc89f4 err module: MSVCR90.dll module version: 9.0.30729.6161 module timestamp: 4dace5b9 exception code: c005 exception offset: 0003ae7a os version: 6.1.7601.2.1.0.256.1 locale: 1040 additional info1: 0a9e additional info2: 0a9e372d3b4ad19135b953a78882e789 additional info3: 0a9e additional info4: 0a9e372d3b4ad19135b953a78882e789 not sure if it is related because it is not logged at every page load, but sometimes apache logs "zend_mm_heap corrupted" thanks in advance -- Edit this bug report at https://bugs.php.net/bug.php?id=55390&edit=1
Bug #55336 [Opn]: mail() function is not thread safe for Windows builds
Edit report at https://bugs.php.net/bug.php?id=55336&edit=1
ID: 55336
Updated by: ka...@php.net
Reported by:grabli_2005 at mail dot ru
Summary:mail() function is not thread safe for Windows
builds
Status: Open
Type: Bug
Package:Network related
Operating System: Windows
PHP Version:5.4.0alpha2
Block user comment: N
Private report: N
New Comment:
Have you encountered any issues specific to this finding? I suppose we could
make a new globals, like PW32G for SendMail and stash the variables in there.
Previous Comments:
[2011-08-03 18:20:59] grabli_2005 at mail dot ru
switch status to open, see details in previous comment
[2011-08-01 13:40:27] grabli_2005 at mail dot ru
I`ve provide this patches as reference only, not as product quality code
replacement.
The only difference that I note since 5.3.0 is FormatEmailAddress function,
that omits <> around emails.
You can check my statment:
look at /ext/standard/mail.c function php_mail
Here nix path: sendmail = popen(sendmail_cmd, "w");
Here win32 path: if (TSendMail(INI_STR("SMTP"), &tsm_err, &tsm_errmsg, hdr,
subject, to, message, NULL, NULL, NULL TSRMLS_CC) == FAILURE) {
TSendMail located in win32\sendmail.c
here global variables:
#ifndef THREAD_SAFE
char Buffer[MAIL_BUFFER_SIZE];
/* socket related data */
SOCKET sc;
#ifndef NETWARE
WSADATA Data;
struct hostent *adr;
int WinsockStarted;
/* values set by the constructor */
char *AppName;
#endif /* NETWARE */
SOCKADDR_IN sock_in;
char MailHost[HOST_NAME_LEN];
char LocalHost[HOST_NAME_LEN];
#endif
It`s placed under #ifndef THREAD_SAFE, but THREAD_SAFE not defined anywhere
even when compile with ZTS. More often _THREAD_SAFE used around the code.
If you define THREAD_SAFE it`s break sendmail.c compilation, because rest of
code uses this variables without any define switch.
You can simply debug or place debug printf() in TSendMail and see that this
code executed and uses global variables.
win32\time.c have same issue.
[2011-08-01 12:55:11] paj...@php.net
Please provide a patch against 5.3 and 5.4.
Also I'm not sure about your statement.
[2011-08-01 12:02:42] grabli_2005 at mail dot ru
fixed typo in title
[2011-08-01 11:50:39] grabli_2005 at mail dot ru
Description:
win32\sendmail.c contans static variables and not thread safe.
Test script:
---
It`s not so easy to write test script, because of multithreading and needs of
test SMTP server.
Expected result:
mail() funtion should be thread safe.
I`ve found this bug years ago. I`ve re-write sendmail.c to not use global
variables for php 5.3.0.
Also I make it compilable for nix build, so mail() may not start heavy sendmail
process and connect directly to local SMTP.
You can get this versions here http://lion.rusfur.net/mail_patch.rar
Actual result:
--
mail() fountion is not thread safe.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55336&edit=1
Bug #55475 [Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1 ID: 55475 Updated by: col...@php.net Reported by:mads at gartneriet dot dk Summary:is_a() triggers autoloader Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.3.7 Assigned To:dmitry Block user comment: N Private report: N New Comment: Well, we have 3 options here: 1) keep it like it is since 5.3.7 2) reverting it to how it worked before 5.3.7 3) change it even more to not use autoload, so that it neither works like <5.3.6 nor 5.3.7 Apparently through your proposed fix you're advocating for (3). If so, I can't see how it would improve the situation in any way. Personally, given that the BC change is minimal, and that we're only adding functionality, (1) seems fine. Correct code existing before 5.3.6 will work just fine anyway. Previous Comments: [2011-08-22 14:44:18] ka...@php.net ... the behaviour I'm talking about is obvious the return value and the fact that the autoloader now is called. [2011-08-22 14:40:46] ka...@php.net I'm talking about the usual procedure we have about changing behaviour, a function suddenly returns the oppersite of what it used to in the middle of a stable series is very unlike to do, even for PHP. I knnow it went from not working to working, but I don't on the fact that such a commonly used function will change behaviour like that. What we should do is to make a big fat warning in the migration guide for 5.3.x -> 5.4.x about it, and in the manual. It would be the same if we changed substr() to be case insensitive in the middle of a release series, lets just not venture in such dark corners. [2011-08-22 14:27:31] col...@php.net But what BC break are you talking about exactly? It went from not-working (returning always false for strings as first argument) to working with autoload. [2011-08-22 13:41:16] ka...@php.net I'm not arguing that the new behaviour is wrong, I believe it is the desired too but I don't agree to break BC in the middle of a stable release series nor as much as I would like to myself to achieve the right behaviour. [2011-08-22 13:31:21] col...@php.net It seems correct to me as well to trigger autoload in this case. It does and always did so for is_subclass_of(), I don't see any reason for a condition of "subclasses_only" to yes or no trigger the autoload. 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 https://bugs.php.net/bug.php?id=55475 -- Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55390 [Opn->Fbk]: win + apache2 + php crash
Edit report at https://bugs.php.net/bug.php?id=55390&edit=1 ID: 55390 Updated by: ka...@php.net Reported by:giorgio dot liscio at email dot it Summary:win + apache2 + php crash -Status: Open +Status: Feedback Type: Bug Package:*General Issues Operating System: windows 7 x64 ultimate PHP Version:5.4SVN-2011-08-10 (snap) Block user comment: N Private report: N New Comment: Do you have any extensions like Xdebug, APC or other extensions that may hook into the include construct? Previous Comments: [2011-08-10 06:24:23] giorgio dot liscio at email dot it Description: i can't identify the problem yet but php simply crash when i include a file the included file is executed totally but at the end something goes wrong (it is not a simple include, i'm trying to identify the code that crashes apache) according to windows php snaps: Thursday, July 28, 2011 2:33 AM r313803 <-- this works Tuesday, August 02, 2011 11:52 AM r314086 <-- this crashes ... and crashes with latest snap too event name: APPCRASH app name: httpd.exe app vers: 2.2.17.0 timestamp: 4cbc89f4 err module: MSVCR90.dll module version: 9.0.30729.6161 module timestamp: 4dace5b9 exception code: c005 exception offset: 0003ae7a os version: 6.1.7601.2.1.0.256.1 locale: 1040 additional info1: 0a9e additional info2: 0a9e372d3b4ad19135b953a78882e789 additional info3: 0a9e additional info4: 0a9e372d3b4ad19135b953a78882e789 not sure if it is related because it is not logged at every page load, but sometimes apache logs "zend_mm_heap corrupted" thanks in advance -- Edit this bug report at https://bugs.php.net/bug.php?id=55390&edit=1
Bug #55475 [Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1
ID: 55475
Updated by: ka...@php.net
Reported by:mads at gartneriet dot dk
Summary:is_a() triggers autoloader
Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
... the behaviour I'm talking about is obvious the return value and the fact
that the autoloader now is called.
Previous Comments:
[2011-08-22 14:40:46] ka...@php.net
I'm talking about the usual procedure we have about changing behaviour, a
function suddenly returns the oppersite of what it used to in the middle of a
stable series is very unlike to do, even for PHP.
I knnow it went from not working to working, but I don't on the fact that such
a commonly used function will change behaviour like that. What we should do is
to make a big fat warning in the migration guide for 5.3.x -> 5.4.x about it,
and in the manual.
It would be the same if we changed substr() to be case insensitive in the
middle of a release series, lets just not venture in such dark corners.
[2011-08-22 14:27:31] col...@php.net
But what BC break are you talking about exactly?
It went from not-working (returning always false for strings as first argument)
to working with autoload.
[2011-08-22 13:41:16] ka...@php.net
I'm not arguing that the new behaviour is wrong, I believe it is the desired
too but I don't agree to break BC in the middle of a stable release series nor
as much as I would like to myself to achieve the right behaviour.
[2011-08-22 13:31:21] col...@php.net
It seems correct to me as well to trigger autoload in this case. It does and
always did so for is_subclass_of(), I don't see any reason for a condition of
"subclasses_only" to yes or no trigger the autoload.
[2011-08-22 11:00:28] dmi...@php.net
Before the patch, is_a() didn't accept string as the first argument at all, so
it always returned "false" and never triggered __autoload(). The proposed patch
didn't revert to original behavior. It just disables autoloading and may lead
to wrong result.
class a {}
class b extends a {}
var_dump(is_a("b", "a")); // it was false before 5.3.7, now it's true
I would say that the old behaviour was wrong, especially because "instanceof"
and is_subclass_of() already implemented support for string arguments.
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
https://bugs.php.net/bug.php?id=55475
--
Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55475 [Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1
ID: 55475
Updated by: ka...@php.net
Reported by:mads at gartneriet dot dk
Summary:is_a() triggers autoloader
Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
I'm talking about the usual procedure we have about changing behaviour, a
function suddenly returns the oppersite of what it used to in the middle of a
stable series is very unlike to do, even for PHP.
I knnow it went from not working to working, but I don't on the fact that such
a commonly used function will change behaviour like that. What we should do is
to make a big fat warning in the migration guide for 5.3.x -> 5.4.x about it,
and in the manual.
It would be the same if we changed substr() to be case insensitive in the
middle of a release series, lets just not venture in such dark corners.
Previous Comments:
[2011-08-22 14:27:31] col...@php.net
But what BC break are you talking about exactly?
It went from not-working (returning always false for strings as first argument)
to working with autoload.
[2011-08-22 13:41:16] ka...@php.net
I'm not arguing that the new behaviour is wrong, I believe it is the desired
too but I don't agree to break BC in the middle of a stable release series nor
as much as I would like to myself to achieve the right behaviour.
[2011-08-22 13:31:21] col...@php.net
It seems correct to me as well to trigger autoload in this case. It does and
always did so for is_subclass_of(), I don't see any reason for a condition of
"subclasses_only" to yes or no trigger the autoload.
[2011-08-22 11:00:28] dmi...@php.net
Before the patch, is_a() didn't accept string as the first argument at all, so
it always returned "false" and never triggered __autoload(). The proposed patch
didn't revert to original behavior. It just disables autoloading and may lead
to wrong result.
class a {}
class b extends a {}
var_dump(is_a("b", "a")); // it was false before 5.3.7, now it's true
I would say that the old behaviour was wrong, especially because "instanceof"
and is_subclass_of() already implemented support for string arguments.
[2011-08-22 10:30:19] ka...@php.net
The following patch has been added/updated:
Patch Name: bug55475
Revision: 1314009019
URL:
https://bugs.php.net/patch-display.php?bug=55475&patch=bug55475&revision=1314009019
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
https://bugs.php.net/bug.php?id=55475
--
Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55414 [Opn->Fbk]: Segmentation fault with MySQLi_Result::fetch_fields()
Edit report at https://bugs.php.net/bug.php?id=55414&edit=1
ID: 55414
Updated by: ka...@php.net
Reported by:jbboehr at gmail dot com
Summary:Segmentation fault with
MySQLi_Result::fetch_fields()
-Status: Open
+Status: Feedback
Type: Bug
Package:MySQLi related
Operating System: CentOS release 5.6 (Final)
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Hi
Does this happen with PHP 5.3.7, what MySQL server version are you using and
what MySQL client library is PHP linked against (libmysql or mysqlnd)?
Previous Comments:
[2011-08-16 01:48:29] jbboehr at gmail dot com
PS Thanks for the gdb
[2011-08-16 01:48:02] jbboehr at gmail dot com
@lgandras For now, we're just using a work-around case for MySQLi, maybe it'll
help you:
if( $adapter instanceof Zend_Db_Adapter_Mysqli ) {
// Fixes MySQLI segfault in fetch_fields() with SHOW ENGINES
$connection = $adapter->getConnection();
$result = mysqli_query($connection, 'SHOW ENGINES');
if ( !$result instanceof MySQLi_STMT ){
return $this->_error('badAdapter');
}
$data = array();
while ( $row = $result->fetch_array() ){
$data[] = $row;
}
} else {
try {
$data = $adapter->query('SHOW ENGINES')->fetchAll();
} catch( Exception $e ) {
return $this->_error('badAdapter');
}
}
[2011-08-16 01:33:19] lgandras at gmail dot com
Hi,
Thank you so much. I was just posting my bug without a reproducible script
https://bugs.php.net/bug.php?id=55431. Here's your gdb =)
#0 0x0841f2e8 in add_property_string_ex (arg=0x907af64, key=0x87ad4cc
"catalog", key_len=8, str=0x31313230 ,
duplicate=1)
at /home/cpeasyapache/src/php-5.3.6/Zend/zend_API.c:1524
#1 0x081d7628 in php_add_field_properties (value=0x907af64, field=0x90fc6e0)
at /home/cpeasyapache/src/php-5.3.6/ext/mysqli/mysqli_api.c:1056
#2 0x081d79b7 in zif_mysqli_fetch_fields (ht=0, return_value=0x907ae80,
return_value_ptr=0x0, this_ptr=0x907a9e8, return_value_used=0)
at /home/cpeasyapache/src/php-5.3.6/ext/mysqli/mysqli_api.c:1114
#3 0x0844632f in zend_do_fcall_common_helper_SPEC (execute_data=0x90a6e50) at
/home/cpeasyapache/src/php-5.3.6/Zend/zend_vm_execute.h:316
#4 0x08446f6b in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x90a6e50)
at /home/cpeasyapache/src/php-5.3.6/Zend/zend_vm_execute.h:421
#5 0x084456fe in execute (op_array=0x90783f0) at
/home/cpeasyapache/src/php-5.3.6/Zend/zend_vm_execute.h:107
#6 0x08419b44 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/home/cpeasyapache/src/php-5.3.6/Zend/zend.c:1194
#7 0x083ad584 in php_execute_script (primary_file=0xbf8cbb04) at
/home/cpeasyapache/src/php-5.3.6/main/main.c:2268
#8 0x084e6f64 in main (argc=2, argv=0xbf8cbc64) at
/home/cpeasyapache/src/php-5.3.6/sapi/cli/php_cli.c:1193
I'm exactly in the same situation as you. I can't use PHP 5.3.6. This doesn't
seem to happen in PHP 5.3.5.
[2011-08-13 01:00:56] jbboehr at gmail dot com
Ok, so gdb was not installed on the server (sigh), however here's part of the
strace, maybe that will help.
connect(4, {sa_family=AF_FILE, path="/var/lib/mysql/mysql.sock"...}, 110) = 0
setsockopt(4, SOL_SOCKET, SO_RCVTIMEO, "\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0",
16) = 0
setsockopt(4, SOL_SOCKET, SO_SNDTIMEO, "\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0",
16) = 0
setsockopt(4, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation not
supported)
setsockopt(4, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
read(4, ">\0\0\0\n5.0.92-community\0\350\352^\0@Dp,%u"..., 16384) = 66
stat("/usr/share/mysql/charsets/Index.xml", {st_mode=S_IFREG|0755,
st_size=18173, ...}) = 0
open("/usr/share/mysql/charsets/Index.xml", O_RDONLY) = 5
read(5, "http://stackoverflow.com/questions/6769515/php-programming-seg-fault
PHP Version => 5.3.6
Configure Command => './configure' '--disable-fileinfo' '--enable-bcmath' '--
enable-calendar' '--enable-exif' '--enable-ftp' '--enable-gd-native-ttf' '--
enable-libxml' '--enable-magic-quotes' '--enable-mbstring'
'--enable-pdo=shared'
'--enable-sockets' '--enable-zend-multibyte' '--enable-zip' '--
prefix=/usr/local' '--with-apxs2=/usr/local/apache/bin/apxs' '--with-bz2' '--
with-curl=/opt/curlssl/' '--with-curlwrappers' '--with-freetype-dir=/usr' '--
with-gd' '--with-gettext' '--with-imap=/opt/php_with_imap_client/' '--with-imap-
ssl=/usr' '--with-jpeg-dir=/usr' '--with-kerberos' '--with-libdir=lib64' '--
with-libexpat-dir=/usr' '--with-libxml-dir=/opt/xml2/' '--with-
mcrypt=/opt/libmcrypt/' '--with-mm=/opt/mm/' '--with-my
Bug #55415 [Opn->Asn]: php_info produces invalid anchor names
Edit report at https://bugs.php.net/bug.php?id=55415&edit=1
ID: 55415
Updated by: ka...@php.net
Reported by:callum at lynxphp dot com
Summary:php_info produces invalid anchor names
-Status: Open
+Status: Assigned
Type: Bug
Package:PHP options/info functions
Operating System: OS X / Windows
PHP Version:5.3.6
-Assigned To:
+Assigned To:kalle
Block user comment: N
Private report: N
New Comment:
I agree Johannes that php_url_encode() should be used, I'm assigning this to
myself to try play around with it and see if I can get a working solution for
when 5.3.8 is packaged
Previous Comments:
[2011-08-15 22:00:59] johan...@php.net
There might be other "bad" characters in the name, not only a space. So I think
php_url_encode() should be used.
About your patch: Mind that c does no garbage collection so you'd create two
memory leaks. A better version might be along the lines of
if (!sapi_module.phpinfo_as_text) {
int len = 0;
char *url_name = php_url_encode(zend_module->name,
strlen(zend_module->name), &len);
php_printf("%s\n", url_name,
zend_module->name);
efree(url_name);
}
Didn't test it though.
/mind that declarations in
[2011-08-13 11:24:05] callum at lynxphp dot com
I don't know whether I got the patch file right; I couldn't find any
documentation
[2011-08-13 09:40:00] callum at lynxphp dot com
Description:
A few modules in PHP cause php_info to print invalid anchor names:
Zend Optimizer
The anchor name should not contain a space - this is invalid.
This bug can be replicated on a vanilla install of PHP with Zend Optimiser
installed.
Test script:
---
https://bugs.php.net/bug.php?id=55415&edit=1
Bug #55475 [Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1
ID: 55475
Updated by: col...@php.net
Reported by:mads at gartneriet dot dk
Summary:is_a() triggers autoloader
Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
But what BC break are you talking about exactly?
It went from not-working (returning always false for strings as first argument)
to working with autoload.
Previous Comments:
[2011-08-22 13:41:16] ka...@php.net
I'm not arguing that the new behaviour is wrong, I believe it is the desired
too but I don't agree to break BC in the middle of a stable release series nor
as much as I would like to myself to achieve the right behaviour.
[2011-08-22 13:31:21] col...@php.net
It seems correct to me as well to trigger autoload in this case. It does and
always did so for is_subclass_of(), I don't see any reason for a condition of
"subclasses_only" to yes or no trigger the autoload.
[2011-08-22 11:00:28] dmi...@php.net
Before the patch, is_a() didn't accept string as the first argument at all, so
it always returned "false" and never triggered __autoload(). The proposed patch
didn't revert to original behavior. It just disables autoloading and may lead
to wrong result.
class a {}
class b extends a {}
var_dump(is_a("b", "a")); // it was false before 5.3.7, now it's true
I would say that the old behaviour was wrong, especially because "instanceof"
and is_subclass_of() already implemented support for string arguments.
[2011-08-22 10:30:19] ka...@php.net
The following patch has been added/updated:
Patch Name: bug55475
Revision: 1314009019
URL:
https://bugs.php.net/patch-display.php?bug=55475&patch=bug55475&revision=1314009019
[2011-08-22 10:29:51] ka...@php.net
Zeev, although the functionality might appear as it should be then we should
not make sudden changes like that in the middle of a stable branch, we should
patch up 5.3 and keep the behaviour in 5.4 if its indeed intended atleast to
comply with previous versions.
The fix for 5.3 is simple, attached
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
https://bugs.php.net/bug.php?id=55475
--
Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Req #55428 [Opn->Asn]: E_RECOVERABLE_ERROR when output buffering in output buffering handler
Edit report at https://bugs.php.net/bug.php?id=55428&edit=1 ID: 55428 Updated by: ka...@php.net Reported by:nicolas dot grekas+php at gmail dot com Summary:E_RECOVERABLE_ERROR when output buffering in output buffering handler -Status: Open +Status: Assigned Type: Feature/Change Request Package:Output Control Operating System: any PHP Version:5.3.6 -Assigned To: +Assigned To:kalle Block user comment: N Private report: N Previous Comments: [2011-08-22 14:22:18] ka...@php.net I agree that we should change to use E_RECOVERABLE_ERROR here, as we don't leave the Engine in an unresolverable state (as the output layer is in the PHP part of the package). As for the function suggestion, it doesn't make much sense to add a function to check if you are in a function for a function which purpose is to be used as a callback for ob_start(). [2011-08-15 22:00:21] nicolas dot grekas+php at gmail dot com Description: Output buffering inside output buffering handler is currently forbidden. Ideally, this limitation could be removed, but as this may be too much work, I mostly really miss some way to test whether my code is running inside an output buffering handler or not (for example in a custom error handler). PHP really miss a way to check for this situation. Currently, when using output buffering in an output buffering handler context, an E_ERROR is thrown. Could it be possible to trigger an E_RECOVERABLE_ERROR instead? This would allow me to catch the situation and degrade gracefully. Or maybe a new special function "ob_in_handler()", returning a boolean, is a better idea ? Test script: --- Expected result: PHP Catchable fatal error: ob_start(): Cannot use output buffering in output buffering display handlers in [...] on line 5 Actual result: -- PHP Fatal error: ob_start(): Cannot use output buffering in output buffering display handlers in [...] on line 5 -- Edit this bug report at https://bugs.php.net/bug.php?id=55428&edit=1
Req #55428 [Opn]: E_RECOVERABLE_ERROR when output buffering in output buffering handler
Edit report at https://bugs.php.net/bug.php?id=55428&edit=1 ID: 55428 Updated by: ka...@php.net Reported by:nicolas dot grekas+php at gmail dot com Summary:E_RECOVERABLE_ERROR when output buffering in output buffering handler Status: Open Type: Feature/Change Request Package:Output Control Operating System: any PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I agree that we should change to use E_RECOVERABLE_ERROR here, as we don't leave the Engine in an unresolverable state (as the output layer is in the PHP part of the package). As for the function suggestion, it doesn't make much sense to add a function to check if you are in a function for a function which purpose is to be used as a callback for ob_start(). Previous Comments: [2011-08-15 22:00:21] nicolas dot grekas+php at gmail dot com Description: Output buffering inside output buffering handler is currently forbidden. Ideally, this limitation could be removed, but as this may be too much work, I mostly really miss some way to test whether my code is running inside an output buffering handler or not (for example in a custom error handler). PHP really miss a way to check for this situation. Currently, when using output buffering in an output buffering handler context, an E_ERROR is thrown. Could it be possible to trigger an E_RECOVERABLE_ERROR instead? This would allow me to catch the situation and degrade gracefully. Or maybe a new special function "ob_in_handler()", returning a boolean, is a better idea ? Test script: --- Expected result: PHP Catchable fatal error: ob_start(): Cannot use output buffering in output buffering display handlers in [...] on line 5 Actual result: -- PHP Fatal error: ob_start(): Cannot use output buffering in output buffering display handlers in [...] on line 5 -- Edit this bug report at https://bugs.php.net/bug.php?id=55428&edit=1
Req #55467 [Opn->Asn]: phpinfo: PHP Variables with $ and single quotes
Edit report at https://bugs.php.net/bug.php?id=55467&edit=1 ID: 55467 Updated by: ka...@php.net Reported by:virsacer at web dot de Summary:phpinfo: PHP Variables with $ and single quotes -Status: Open +Status: Assigned Type: Feature/Change Request Package:PHP options/info functions PHP Version:trunk-SVN-2011-08-20 (snap) -Assigned To: +Assigned To:kalle Block user comment: N Private report: N New Comment: Guess we can do that while fixing the boxing thing in mbstring Previous Comments: [2011-08-20 18:26:12] virsacer at web dot de Description: Show "PHP Variables" with a leading "$" and single quotes in phpinfo(); -- Edit this bug report at https://bugs.php.net/bug.php?id=55467&edit=1
Bug #55441 [Opn->Fbk]: \Phar::createDefaultStub() does not handle its arguments
Edit report at https://bugs.php.net/bug.php?id=55441&edit=1
ID: 55441
Updated by: ka...@php.net
Reported by:frederic dot hardy at mageekbox dot net
Summary:\Phar::createDefaultStub() does not handle its
arguments
-Status: Open
+Status: Feedback
Type: Bug
Package:PHAR related
Operating System: MacOS X 10.6.8
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
By quickly skimming over the source it seems that in order for this function to
work both parameters must have a value. Have you tried that?
Previous Comments:
[2011-08-17 13:43:16] frederic dot hardy at mageekbox dot net
Description:
\Phar::createDefaultStub() takes two optional arguments.
With these arguments, the user can defined file in phar archive which will be
used
in stub.
However, these arguments seems to be not used by \Phar::createDefaultStub().
Test script:
---
';
$phar->createDefaultStub('stub.php');
Expected result:
This is the stub !
Actual result:
--
PHP Warning: include(phar:///path/to/my.phar/index.php): failed to open
stream:
phar error: "index.php" is not a file in phar "/path/to/my.phar" in
/path/to/my.phar on line 9
--
Edit this bug report at https://bugs.php.net/bug.php?id=55441&edit=1
Req #55443 [Opn->Fbk]: 4nd params double_encode
Edit report at https://bugs.php.net/bug.php?id=55443&edit=1 ID: 55443 Updated by: ka...@php.net Reported by:al at instrument dot pl dot ua Summary:4nd params double_encode -Status: Open +Status: Feedback Type: Feature/Change Request Package:*General Issues Operating System: any PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I have no idea what you mean by this report, the parameter is properly documented in already, or are you requesting an example of usage? Previous Comments: [2011-08-17 19:42:04] al at instrument dot pl dot ua Description: Path in Bug #43101: htmlentities(): double_quote vs. double_encode typo --- >From manual page: >http://www.php.net/function.htmlspecialchars%23%D0%9E%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5 --- four params double_encode=true|false present in real, and absent in documentation Test script: --- $links_str = "http://ya.ru?q=search&mmm"; $links_str = htmlspecialchars($links_str,ENT_COMPAT,'UTF-8',$double_encode=false); -- Edit this bug report at https://bugs.php.net/bug.php?id=55443&edit=1
Bug #55444 [Opn->Fbk]: trans-sid enabled; PHPSESSID inserted after end of href on links
Edit report at https://bugs.php.net/bug.php?id=55444&edit=1
ID: 55444
Updated by: ka...@php.net
Reported by:fatman at crackmonkey dot us
Summary:trans-sid enabled; PHPSESSID inserted after end of
href on links
-Status: Open
+Status: Feedback
Type: Bug
Package:Session related
Operating System: Ubuntu 10.04.3 LTS
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
(pressed Enter by accident)
... if the problem persists in 5.3.7 or the upcoming patch level release 5.3.8
then change the status of the bug back to Open
Previous Comments:
[2011-08-22 14:05:31] ka...@php.net
Upgrade PHP first, we don't support 5.3.2 anymore
[2011-08-17 22:33:42] fatman at crackmonkey dot us
Description:
In more detail, OS:
Linux 2.6.32-32-server x86_64 #62-Ubuntu SMP Wed Apr 20 22:07:43 UTC 2011
PHP 5.3.2-1ubuntu4.9 with Suhosin-Patch (cli) (built: May 3 2011 00:45:52)
This is the standard PHP package from Ubuntu Lucid's "main" repo. I did not
compile it. I have enabled the trans-
sid option.
When generating a long list of links, occasionally the trans-sid function will
miss the end of the "href"
attribute and add "?PHPSESSID=73...07" outside the closing double quote mark.
eg:
gallery_36.jpg
...
gallery_37.jpg
Note that since it is outside the quote mark, it is generated with a "?"
instead
of "&". This reliably
happens on the "gallery_37.jpg" link, and the "gallery_18.jpg" link, and a few
others.
Test script:
---
The relevant loop:
while ($row = mysql_fetch_assoc($result)) {
$file = sanitise_html($row["filename"]);
$title = sanitise_html($row["title"]);
?>
https://bugs.php.net/bug.php?id=55444&edit=1
Bug #55444 [Opn]: trans-sid enabled; PHPSESSID inserted after end of href on links
Edit report at https://bugs.php.net/bug.php?id=55444&edit=1
ID: 55444
Updated by: ka...@php.net
Reported by:fatman at crackmonkey dot us
Summary:trans-sid enabled; PHPSESSID inserted after end of
href on links
Status: Open
Type: Bug
Package:Session related
Operating System: Ubuntu 10.04.3 LTS
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Upgrade PHP first, we don't support 5.3.2 anymore
Previous Comments:
[2011-08-17 22:33:42] fatman at crackmonkey dot us
Description:
In more detail, OS:
Linux 2.6.32-32-server x86_64 #62-Ubuntu SMP Wed Apr 20 22:07:43 UTC 2011
PHP 5.3.2-1ubuntu4.9 with Suhosin-Patch (cli) (built: May 3 2011 00:45:52)
This is the standard PHP package from Ubuntu Lucid's "main" repo. I did not
compile it. I have enabled the trans-
sid option.
When generating a long list of links, occasionally the trans-sid function will
miss the end of the "href"
attribute and add "?PHPSESSID=73...07" outside the closing double quote mark.
eg:
gallery_36.jpg
...
gallery_37.jpg
Note that since it is outside the quote mark, it is generated with a "?"
instead
of "&". This reliably
happens on the "gallery_37.jpg" link, and the "gallery_18.jpg" link, and a few
others.
Test script:
---
The relevant loop:
while ($row = mysql_fetch_assoc($result)) {
$file = sanitise_html($row["filename"]);
$title = sanitise_html($row["title"]);
?>
https://bugs.php.net/bug.php?id=55444&edit=1
Req #42322 [Com]: pdo_mysql fetch() throws exception on INSERT statements
Edit report at https://bugs.php.net/bug.php?id=42322&edit=1
ID: 42322
Comment by: rosen at developer dot bg
Reported by:norbert at linuxnetworks dot de
Summary:pdo_mysql fetch() throws exception on INSERT
statements
Status: Open
Type: Feature/Change Request
Package:PDO related
Operating System: Linux Debian Testing
PHP Version:5.2.3
Block user comment: N
Private report: N
New Comment:
The above test was performed on PHP 5.3.6 (cli)
uname -a: Linux gateway 2.6.9-78.0.22.ELsmp #1 SMP Thu Apr 30 19:17:40 EDT 2009
x86_64 x86_64 x86_64 GNU/Linux
Previous Comments:
[2011-08-22 14:00:07] rosen at developer dot bg
I think that the issue here might be that PHP misinterprets what the mysql
client library returns. See this: http://bugs.mysql.com/bug.php?id=706 - as far
as I understand, the C function mysql_errno() is not supposed to return errors
relating to a fetch operation - which means that if mysql_query failed and then
mysql_fetch_row fails due to being at the end of the result set, mysql_errno
will still return the error from mysql_query. This would trick PDO into
thinking that it was the mysql_fetch_row that failed, thowing a PDOException
that refers to a completely different error (the one previously caused by
mysql_query).
Example code:
-
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$res = $dbh->query('SELECT 1'); // result has only one row
foreach ($res as $row) {
// perform another query that fails with an error, but catch the
exception
try {
$dbh->query('blah blah');
} catch (PDOException $e) {
echo "Exception caught.\n";
}
}
Expected output:
Exception caught.
Actual output:
--
Exception caught.
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42000]:
Syntax error or access violation: 1064 You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the right
syntax to use near 'blah blah' at line 1' in ~/bug.php:9
Stack trace:
#0 ~/bug.php(9): unknown()
#1 {main}
thrown in ~/bug.php on line 9
[2008-01-07 17:24:33] u...@php.net
How DB2 Express and Oracle Express deal with the example code...
DB2 Express -
Warning: PDOStatement::fetch(): SQLSTATE[24000]: Invalid cursor state: -9
[IBM][CLI Driver] CLI0115E Invalid cursor state. SQLSTATE=24000
(SQLFetchScroll[4294867297] at
/home/nixnutz/php5/ext/pdo_ibm/ibm_statement.c:867) in
/home/nixnutz/php5/ext/pdo_ibm/tests/bug_42322.php on line 19
Oracle Express -
Warning: PDOStatement::fetch(): SQLSTATE[HY000]: General error: 24374
OCIStmtFetch: ORA-24374: Definition nicht erfolgt vor Abruf oder Ausführen und
Abruf
(/home/nixnutz/php5/ext/pdo_oci/oci_statement.c:467) in
/home/nixnutz/php5/ext/pdo_oci/tests/bug_42322.php
[2008-01-07 12:39:54] u...@php.net
Changing category to PDO.
I don't think this is a bug.
Its hard to say what is "correct" when it comes to PDO. PDO shows many
inconsistencies when comparing different drivers. With MySQL there is no result
set to fetch after executing an INSERT statement.
Fetch is one place where the "PDO specification" states explicitly that drivers
differ in their behaviour:
"The results of this fetch are driver dependent and the data is usually stored
in the driver_data member of the pdo_stmt_t object. The ori and offset
parameters are only meaningful if the statement represents a scrollable cursor.
This function returns 1 for success or 0 in the event of failure."
http://www.php.net/manual/en/internals2.pdo.implementing.php
As no standard behaviour has been defined, how can either MySQL or any other
driver be wrong? I guess this issue should be called a Feature request but not
a bug.
SQLite -> no exception
MySQL -> exception
Postgres -> exception
Ulf
[2007-08-16 19:21:33] norbert at linuxnetworks dot de
Description:
If using the MySQL PDO driver in PDO::ERRMODE_EXCEPTION mode, calling fetch()
after executing an INSERT/UPDATE/DELETE statement throws an exception. Instead,
it should return FALSE in this case like for an empty result set. Please
compare to the SQLite PDO driver which works correctly.
Reproduce code:
---
setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );
try
{
$db->exec("CREATE TABLE IF NOT EXISTS TestTable (id INT)");
$sql = 'INSERT INTO TestTable VALUES ( NULL )';
$query = $db->prepare( $sql );
$query->execute();
while( ( $row = $query->fetch( PDO::FETCH_ASSOC ) ) !== FALSE ) {}
$q
Req #42322 [Com]: pdo_mysql fetch() throws exception on INSERT statements
Edit report at https://bugs.php.net/bug.php?id=42322&edit=1
ID: 42322
Comment by: rosen at developer dot bg
Reported by:norbert at linuxnetworks dot de
Summary:pdo_mysql fetch() throws exception on INSERT
statements
Status: Open
Type: Feature/Change Request
Package:PDO related
Operating System: Linux Debian Testing
PHP Version:5.2.3
Block user comment: N
Private report: N
New Comment:
I think that the issue here might be that PHP misinterprets what the mysql
client library returns. See this: http://bugs.mysql.com/bug.php?id=706 - as far
as I understand, the C function mysql_errno() is not supposed to return errors
relating to a fetch operation - which means that if mysql_query failed and then
mysql_fetch_row fails due to being at the end of the result set, mysql_errno
will still return the error from mysql_query. This would trick PDO into
thinking that it was the mysql_fetch_row that failed, thowing a PDOException
that refers to a completely different error (the one previously caused by
mysql_query).
Example code:
-
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$res = $dbh->query('SELECT 1'); // result has only one row
foreach ($res as $row) {
// perform another query that fails with an error, but catch the
exception
try {
$dbh->query('blah blah');
} catch (PDOException $e) {
echo "Exception caught.\n";
}
}
Expected output:
Exception caught.
Actual output:
--
Exception caught.
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42000]:
Syntax error or access violation: 1064 You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the right
syntax to use near 'blah blah' at line 1' in ~/bug.php:9
Stack trace:
#0 ~/bug.php(9): unknown()
#1 {main}
thrown in ~/bug.php on line 9
Previous Comments:
[2008-01-07 17:24:33] u...@php.net
How DB2 Express and Oracle Express deal with the example code...
DB2 Express -
Warning: PDOStatement::fetch(): SQLSTATE[24000]: Invalid cursor state: -9
[IBM][CLI Driver] CLI0115E Invalid cursor state. SQLSTATE=24000
(SQLFetchScroll[4294867297] at
/home/nixnutz/php5/ext/pdo_ibm/ibm_statement.c:867) in
/home/nixnutz/php5/ext/pdo_ibm/tests/bug_42322.php on line 19
Oracle Express -
Warning: PDOStatement::fetch(): SQLSTATE[HY000]: General error: 24374
OCIStmtFetch: ORA-24374: Definition nicht erfolgt vor Abruf oder Ausführen und
Abruf
(/home/nixnutz/php5/ext/pdo_oci/oci_statement.c:467) in
/home/nixnutz/php5/ext/pdo_oci/tests/bug_42322.php
[2008-01-07 12:39:54] u...@php.net
Changing category to PDO.
I don't think this is a bug.
Its hard to say what is "correct" when it comes to PDO. PDO shows many
inconsistencies when comparing different drivers. With MySQL there is no result
set to fetch after executing an INSERT statement.
Fetch is one place where the "PDO specification" states explicitly that drivers
differ in their behaviour:
"The results of this fetch are driver dependent and the data is usually stored
in the driver_data member of the pdo_stmt_t object. The ori and offset
parameters are only meaningful if the statement represents a scrollable cursor.
This function returns 1 for success or 0 in the event of failure."
http://www.php.net/manual/en/internals2.pdo.implementing.php
As no standard behaviour has been defined, how can either MySQL or any other
driver be wrong? I guess this issue should be called a Feature request but not
a bug.
SQLite -> no exception
MySQL -> exception
Postgres -> exception
Ulf
[2007-08-16 19:21:33] norbert at linuxnetworks dot de
Description:
If using the MySQL PDO driver in PDO::ERRMODE_EXCEPTION mode, calling fetch()
after executing an INSERT/UPDATE/DELETE statement throws an exception. Instead,
it should return FALSE in this case like for an empty result set. Please
compare to the SQLite PDO driver which works correctly.
Reproduce code:
---
setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );
try
{
$db->exec("CREATE TABLE IF NOT EXISTS TestTable (id INT)");
$sql = 'INSERT INTO TestTable VALUES ( NULL )';
$query = $db->prepare( $sql );
$query->execute();
while( ( $row = $query->fetch( PDO::FETCH_ASSOC ) ) !== FALSE ) {}
$query->closeCursor();
}
catch( PDOException $pe ) {
echo 'Got PDOException: ' . $pe->getMessage();
}
?>
Expected result:
$query->fetch() should return FALSE, as it is not an error to call fetch() for
an INSERT statement, because it might be unknown what type of
Bug #55468 [Opn->Fbk]: UnexpectedValueException caused by an unreleased handle or something
Edit report at https://bugs.php.net/bug.php?id=55468&edit=1 ID: 55468 Updated by: ka...@php.net Reported by:php at tracking-celebs dot info Summary:UnexpectedValueException caused by an unreleased handle or something -Status: Open +Status: Feedback Type: Bug Package:SPL related Operating System: win32 PHP Version:Irrelevant Block user comment: N Private report: N Previous Comments: [2011-08-22 13:58:59] ka...@php.net At first glance it doesn't looks like a problem in PHP itself but more that you haven't granted yourself the permission to delete the folder on Windows. Have you tried to chmod or similar it? [2011-08-20 19:56:20] php at tracking-celebs dot info Description: After using a DirectoryIterator on a folder, then removing said folder, using another iterator to iterate on the folder's parent will see/try to look into the removed folder. This only happens on Windows, so maybe due to a cache somewhere or something. Tried adding a clearstatcache() just in case, but that doesn't change anything. FYI if you replace the first DirectoryIterator by a: opendir($foo); without calling closedir() you get the same error, hence why I suggested it might be a handle not (properly) released or something. Test script: --- https://bugs.php.net/bug.php?id=55468&edit=1
Bug #55468 [Opn]: UnexpectedValueException caused by an unreleased handle or something
Edit report at https://bugs.php.net/bug.php?id=55468&edit=1 ID: 55468 Updated by: ka...@php.net Reported by:php at tracking-celebs dot info Summary:UnexpectedValueException caused by an unreleased handle or something Status: Open Type: Bug Package:SPL related Operating System: win32 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: At first glance it doesn't looks like a problem in PHP itself but more that you haven't granted yourself the permission to delete the folder on Windows. Have you tried to chmod or similar it? Previous Comments: [2011-08-20 19:56:20] php at tracking-celebs dot info Description: After using a DirectoryIterator on a folder, then removing said folder, using another iterator to iterate on the folder's parent will see/try to look into the removed folder. This only happens on Windows, so maybe due to a cache somewhere or something. Tried adding a clearstatcache() just in case, but that doesn't change anything. FYI if you replace the first DirectoryIterator by a: opendir($foo); without calling closedir() you get the same error, hence why I suggested it might be a handle not (properly) released or something. Test script: --- https://bugs.php.net/bug.php?id=55468&edit=1
Bug #55469 [Opn->Asn]: phpinfo: Wrong licensetext display
Edit report at https://bugs.php.net/bug.php?id=55469&edit=1 ID: 55469 Updated by: ka...@php.net Reported by:virsacer at web dot de Summary:phpinfo: Wrong licensetext display -Status: Open +Status: Assigned Type: Bug Package:PHP options/info functions PHP Version:trunk-SVN-2011-08-20 (snap) -Assigned To: +Assigned To:kalle Block user comment: N Private report: N New Comment: I'll take this one and commit the patches after 5.3.8 have been packaged, so it will be included in 5.3.9. Previous Comments: [2011-08-20 20:07:42] virsacer at web dot de Description: mbstring uses a "table header" instead of a "box" (like all others) to display it's license information -- Edit this bug report at https://bugs.php.net/bug.php?id=55469&edit=1
Req #55476 [Opn->Fbk]: Method doesn't exist with magic method for soap
Edit report at https://bugs.php.net/bug.php?id=55476&edit=1
ID: 55476
Updated by: ka...@php.net
Reported by:donaldinou at gmail dot com
Summary:Method doesn't exist with magic method for soap
-Status: Open
+Status: Feedback
Type: Feature/Change Request
Package:*General Issues
Operating System: Linux
PHP Version:5.3.7
Block user comment: N
Private report: N
New Comment:
And the error from $r is? Please be more verbose
Previous Comments:
[2011-08-22 12:16:29] donaldinou at gmail dot com
Description:
---
>From manual page: http://www.php.net/reflectionmethod.invokeargs%23Description
---
There is differences between call_user_func_array and Reflection::invokeArgs
method. Some magic methods are correctly called by call_user_func_array, but
not
in Reflection Object
Test script:
---
if I do this:
// Example: $clientSoap->runTransaction($arguments)
// call_user_func_array
$result = call_user_func_array( array($clientSoap, 'runTransaction'),
$arguments );
if (!is_soap_fault($result)) {
echo 'The method __doRequest from SoapClient object is called (This is what
we want).';
}
// with reflection
$reflectionMethod = new ReflectionMethod('SoapClient', 'runTransaction');
try {
$result = $reflectionMethod->invokeArgs( $clientSoap, $arguments );
if (!is_soap_fault($result)) {
echo 'The method __doRequest from SoapClient object is called (This is what
we want).';
}
} catch (ReflectionException $r) {
echo 'The method __doRequest is never called because the methode invokeArgs
throw a ReflectionException.';
}
Expected result:
This should be display:
The method __doRequest from SoapClient object is called (This is what we want).
The method __doRequest from SoapClient object is called (This is what we want).
Actual result:
--
The method __doRequest from SoapClient object is called (This is what we want).
The method __doRequest is never called because the methode invokeArgs throw a
ReflectionException.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55476&edit=1
Bug #55475 [Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1
ID: 55475
Updated by: ka...@php.net
Reported by:mads at gartneriet dot dk
Summary:is_a() triggers autoloader
Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
I'm not arguing that the new behaviour is wrong, I believe it is the desired
too but I don't agree to break BC in the middle of a stable release series nor
as much as I would like to myself to achieve the right behaviour.
Previous Comments:
[2011-08-22 13:31:21] col...@php.net
It seems correct to me as well to trigger autoload in this case. It does and
always did so for is_subclass_of(), I don't see any reason for a condition of
"subclasses_only" to yes or no trigger the autoload.
[2011-08-22 11:00:28] dmi...@php.net
Before the patch, is_a() didn't accept string as the first argument at all, so
it always returned "false" and never triggered __autoload(). The proposed patch
didn't revert to original behavior. It just disables autoloading and may lead
to wrong result.
class a {}
class b extends a {}
var_dump(is_a("b", "a")); // it was false before 5.3.7, now it's true
I would say that the old behaviour was wrong, especially because "instanceof"
and is_subclass_of() already implemented support for string arguments.
[2011-08-22 10:30:19] ka...@php.net
The following patch has been added/updated:
Patch Name: bug55475
Revision: 1314009019
URL:
https://bugs.php.net/patch-display.php?bug=55475&patch=bug55475&revision=1314009019
[2011-08-22 10:29:51] ka...@php.net
Zeev, although the functionality might appear as it should be then we should
not make sudden changes like that in the middle of a stable branch, we should
patch up 5.3 and keep the behaviour in 5.4 if its indeed intended atleast to
comply with previous versions.
The fix for 5.3 is simple, attached
[2011-08-22 10:12:48] z...@php.net
Discussed with Dmitry, the current functionality appears to be correct.
is_a('foo', 'bar') *can* be true even if class foo isn't loaded, and we'll only
know that if we try to load 'foo'.
This is different from is_a($obj, 'non_existent_class'), which we can resolve
as
'false' in case non_existent_class isn't loaded without trying to load it
(there
can't be an instance of a class that doesn't exist).
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
https://bugs.php.net/bug.php?id=55475
--
Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55475 [Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1
ID: 55475
Updated by: col...@php.net
Reported by:mads at gartneriet dot dk
Summary:is_a() triggers autoloader
Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
It seems correct to me as well to trigger autoload in this case. It does and
always did so for is_subclass_of(), I don't see any reason for a condition of
"subclasses_only" to yes or no trigger the autoload.
Previous Comments:
[2011-08-22 11:00:28] dmi...@php.net
Before the patch, is_a() didn't accept string as the first argument at all, so
it always returned "false" and never triggered __autoload(). The proposed patch
didn't revert to original behavior. It just disables autoloading and may lead
to wrong result.
class a {}
class b extends a {}
var_dump(is_a("b", "a")); // it was false before 5.3.7, now it's true
I would say that the old behaviour was wrong, especially because "instanceof"
and is_subclass_of() already implemented support for string arguments.
[2011-08-22 10:30:19] ka...@php.net
The following patch has been added/updated:
Patch Name: bug55475
Revision: 1314009019
URL:
https://bugs.php.net/patch-display.php?bug=55475&patch=bug55475&revision=1314009019
[2011-08-22 10:29:51] ka...@php.net
Zeev, although the functionality might appear as it should be then we should
not make sudden changes like that in the middle of a stable branch, we should
patch up 5.3 and keep the behaviour in 5.4 if its indeed intended atleast to
comply with previous versions.
The fix for 5.3 is simple, attached
[2011-08-22 10:12:48] z...@php.net
Discussed with Dmitry, the current functionality appears to be correct.
is_a('foo', 'bar') *can* be true even if class foo isn't loaded, and we'll only
know that if we try to load 'foo'.
This is different from is_a($obj, 'non_existent_class'), which we can resolve
as
'false' in case non_existent_class isn't loaded without trying to load it
(there
can't be an instance of a class that doesn't exist).
[2011-08-22 09:15:23] col...@php.net
1) The underlying implementation is shared between is_a and is_subclass_of.
2) Previously, strings as first argument was not permitted by is_a but
was for is_subclass_of,
3) is_subclass_of always triggered autoload in such cases.
4) Following a fix from Dmitry, the underlying implementation now
allows a string as first argument for is_a as well.
Conclusion: it is now consistent, but if you wrongly used is_a with a
string before, it now triggers autoload because it actually accepts
it.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=55475
--
Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55477 [Opn->Bgs]: crypt() returns inconsistent hashes for non-ASCII characters
Edit report at https://bugs.php.net/bug.php?id=55477&edit=1
ID: 55477
Updated by: bj...@php.net
Reported by:christian at pingdom dot com
Summary:crypt() returns inconsistent hashes for non-ASCII
characters
-Status: Open
+Status: Bogus
Type: Bug
Package:*Encryption and hash functions
Operating System: Linux
PHP Version:5.3.7
Block user comment: N
Private report: N
New Comment:
This is expected, see http://www.openwall.com/lists/announce/2011/06/21/1
You need to use $2x$ for non-ascii, sorry :(
Previous Comments:
[2011-08-22 12:47:41] christian at pingdom dot com
Description:
Hashes generated with crypt() (using Blowfish) on PHP 5.3.5 or 5.3.3 cannot be
validated on 5.3.7, if the hashed strings contain non-ASCII characters. The
reverse is also true, if the hashes were generated on 5.3.7, they cannot be
validated on 5.3.3 or 5.3.5.
Test script:
---
$passwords = array(
// these hashes were generated on PHP 5.3.5-1ubuntu7.2 with Suhosin-Patch
(cli) (built: May 2 2011 23:00:17)
'brownfox' =>
'$2a$07$usesomesillystringforeD/hyr5e1bWX2PzwckMuCRNQMTrQNr72',
'Boxkämpfer' =>
'$2a$07$usesomesillystringfore36pVDWFz65CbxoLgSgVURqHWU4yEqye',
'ÑаÑÑлива' =>
'$2a$07$usesomesillystringforeoM7K1pyDjeAG1F42k34MP.tbiMnNcy.',
'Põdur' => '$2a$07$usesomesillystringfore1iPxMN9wh4Cr2oVR6nmdILWylX9D0iO',
);
foreach ($passwords as $password => $hash)
{
$computedHash = crypt($password, $hash);
if ($computedHash == $hash)
{
echo "hash OK\n";
}
else
{
echo "hash FAIL ($hash != $computedHash)\n";
}
}
Expected result:
hash OK
hash OK
hash OK
hash OK
Actual result:
--
hash OK
hash FAIL ($2a$07$usesomesillystringfore36pVDWFz65CbxoLgSgVURqHWU4yEqye !=
$2a$07$usesomesillystringforeelZZJE6VQ2/DIcx1J.D.htZuAQIV43S)
hash FAIL ($2a$07$usesomesillystringforeoM7K1pyDjeAG1F42k34MP.tbiMnNcy. !=
$2a$07$usesomesillystringforevg24bYcXKv2WUiCZvAH627ba6aubiNC)
hash FAIL ($2a$07$usesomesillystringfore1iPxMN9wh4Cr2oVR6nmdILWylX9D0iO !=
$2a$07$usesomesillystringforeuqJNc6ZnvGzLGss/.ZcwQdygkbYamRq)
--
Edit this bug report at https://bugs.php.net/bug.php?id=55477&edit=1
Sec Bug->Bug #55477 [Opn]: crypt() returns inconsistent hashes for non-ASCII characters
Edit report at https://bugs.php.net/bug.php?id=55477&edit=1
ID: 55477
Updated by: paj...@php.net
Reported by:christian at pingdom dot com
Summary:crypt() returns inconsistent hashes for non-ASCII
characters
Status: Open
-Type: Security
+Type: Bug
Package:*Encryption and hash functions
Operating System: Linux
PHP Version:5.3.7
Block user comment: N
Private report: Y
Previous Comments:
[2011-08-22 12:47:41] christian at pingdom dot com
Description:
Hashes generated with crypt() (using Blowfish) on PHP 5.3.5 or 5.3.3 cannot be
validated on 5.3.7, if the hashed strings contain non-ASCII characters. The
reverse is also true, if the hashes were generated on 5.3.7, they cannot be
validated on 5.3.3 or 5.3.5.
Test script:
---
$passwords = array(
// these hashes were generated on PHP 5.3.5-1ubuntu7.2 with Suhosin-Patch
(cli) (built: May 2 2011 23:00:17)
'brownfox' =>
'$2a$07$usesomesillystringforeD/hyr5e1bWX2PzwckMuCRNQMTrQNr72',
'Boxkämpfer' =>
'$2a$07$usesomesillystringfore36pVDWFz65CbxoLgSgVURqHWU4yEqye',
'ÑаÑÑлива' =>
'$2a$07$usesomesillystringforeoM7K1pyDjeAG1F42k34MP.tbiMnNcy.',
'Põdur' => '$2a$07$usesomesillystringfore1iPxMN9wh4Cr2oVR6nmdILWylX9D0iO',
);
foreach ($passwords as $password => $hash)
{
$computedHash = crypt($password, $hash);
if ($computedHash == $hash)
{
echo "hash OK\n";
}
else
{
echo "hash FAIL ($hash != $computedHash)\n";
}
}
Expected result:
hash OK
hash OK
hash OK
hash OK
Actual result:
--
hash OK
hash FAIL ($2a$07$usesomesillystringfore36pVDWFz65CbxoLgSgVURqHWU4yEqye !=
$2a$07$usesomesillystringforeelZZJE6VQ2/DIcx1J.D.htZuAQIV43S)
hash FAIL ($2a$07$usesomesillystringforeoM7K1pyDjeAG1F42k34MP.tbiMnNcy. !=
$2a$07$usesomesillystringforevg24bYcXKv2WUiCZvAH627ba6aubiNC)
hash FAIL ($2a$07$usesomesillystringfore1iPxMN9wh4Cr2oVR6nmdILWylX9D0iO !=
$2a$07$usesomesillystringforeuqJNc6ZnvGzLGss/.ZcwQdygkbYamRq)
--
Edit this bug report at https://bugs.php.net/bug.php?id=55477&edit=1
[PHP-BUG] Req #55476 [NEW]: Method doesn't exist with magic method for soap
From:
Operating system: Linux
PHP version: 5.3.7
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:Method doesn't exist with magic method for soap
Description:
---
>From manual page:
http://www.php.net/reflectionmethod.invokeargs%23Description
---
There is differences between call_user_func_array and
Reflection::invokeArgs
method. Some magic methods are correctly called by call_user_func_array,
but not
in Reflection Object
Test script:
---
if I do this:
// Example: $clientSoap->runTransaction($arguments)
// call_user_func_array
$result = call_user_func_array( array($clientSoap, 'runTransaction'),
$arguments );
if (!is_soap_fault($result)) {
echo 'The method __doRequest from SoapClient object is called (This is
what we want).';
}
// with reflection
$reflectionMethod = new ReflectionMethod('SoapClient', 'runTransaction');
try {
$result = $reflectionMethod->invokeArgs( $clientSoap, $arguments );
if (!is_soap_fault($result)) {
echo 'The method __doRequest from SoapClient object is called (This is
what we want).';
}
} catch (ReflectionException $r) {
echo 'The method __doRequest is never called because the methode
invokeArgs throw a ReflectionException.';
}
Expected result:
This should be display:
The method __doRequest from SoapClient object is called (This is what we
want).
The method __doRequest from SoapClient object is called (This is what we
want).
Actual result:
--
The method __doRequest from SoapClient object is called (This is what we
want).
The method __doRequest is never called because the methode invokeArgs throw
a
ReflectionException.
--
Edit bug report at https://bugs.php.net/bug.php?id=55476&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55476&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55476&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55476&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55476&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55476&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55476&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55476&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55476&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55476&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55476&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55476&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55476&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55476&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55476&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55476&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55476&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55476&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55476&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55476&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55476&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55476&r=mysqlcfg
Bug #55463 [Ana->Csd]: cli-server missing _SERVER[ REMOTE_ADDR ]
Edit report at https://bugs.php.net/bug.php?id=55463&edit=1 ID: 55463 Updated by: larue...@php.net Reported by:twentyafterfour at gmail dot com Summary:cli-server missing _SERVER[ REMOTE_ADDR ] -Status: Analyzed +Status: Closed Type: Bug Package:Built-in web server Operating System: Linux PHP Version:5.4.0alpha3 -Assigned To: +Assigned To:laruence Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-08-22 11:55:33] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revision&revision=315278 Log: Fixed #55463 (cli-server missing _SERVER[REMOTE_ADDR]) [2011-08-22 11:28:55] larue...@php.net The following patch has been added/updated: Patch Name: bug55463.diff Revision: 1314012535 URL: https://bugs.php.net/patch-display.php?bug=55463&patch=bug55463.diff&revision=1314012535 [2011-08-19 16:17:33] twentyafterfour at gmail dot com Description: A loop over all available server variables produces just the following: _SERVER[DOCUMENT_ROOT] _SERVER[HTTP_HOST] _SERVER[HTTP_COOKIE] _SERVER[REQUEST_URI] _SERVER[REQUEST_METHOD] _SERVER[PHP_SELF] _SERVER[SCRIPT_FILENAME] _SERVER[REQUEST_TIME] _SERVER[argv] _SERVER[argc] REMOTE_* variables are missing and phpinfo() shows no traces of remote host information. Test script: --- Expected result: REMOTE_ADDR is set Actual result: -- REMOTE_ADDR missing -- Edit this bug report at https://bugs.php.net/bug.php?id=55463&edit=1
Bug #55463 [Opn->Ana]: cli-server missing _SERVER[ REMOTE_ADDR ]
Edit report at https://bugs.php.net/bug.php?id=55463&edit=1 ID: 55463 Updated by: larue...@php.net Reported by:twentyafterfour at gmail dot com Summary:cli-server missing _SERVER[ REMOTE_ADDR ] -Status: Open +Status: Analyzed Type: Bug Package:Built-in web server Operating System: Linux PHP Version:5.4.0alpha3 Block user comment: N Private report: N Previous Comments: [2011-08-22 11:28:55] larue...@php.net The following patch has been added/updated: Patch Name: bug55463.diff Revision: 1314012535 URL: https://bugs.php.net/patch-display.php?bug=55463&patch=bug55463.diff&revision=1314012535 [2011-08-19 16:17:33] twentyafterfour at gmail dot com Description: A loop over all available server variables produces just the following: _SERVER[DOCUMENT_ROOT] _SERVER[HTTP_HOST] _SERVER[HTTP_COOKIE] _SERVER[REQUEST_URI] _SERVER[REQUEST_METHOD] _SERVER[PHP_SELF] _SERVER[SCRIPT_FILENAME] _SERVER[REQUEST_TIME] _SERVER[argv] _SERVER[argc] REMOTE_* variables are missing and phpinfo() shows no traces of remote host information. Test script: --- Expected result: REMOTE_ADDR is set Actual result: -- REMOTE_ADDR missing -- Edit this bug report at https://bugs.php.net/bug.php?id=55463&edit=1
Bug #55463 [PATCH]: cli-server missing _SERVER[ REMOTE_ADDR ]
Edit report at https://bugs.php.net/bug.php?id=55463&edit=1 ID: 55463 Patch added by: larue...@php.net Reported by:twentyafterfour at gmail dot com Summary:cli-server missing _SERVER[ REMOTE_ADDR ] Status: Open Type: Bug Package:Built-in web server Operating System: Linux PHP Version:5.4.0alpha3 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug55463.diff Revision: 1314012535 URL: https://bugs.php.net/patch-display.php?bug=55463&patch=bug55463.diff&revision=1314012535 Previous Comments: [2011-08-19 16:17:33] twentyafterfour at gmail dot com Description: A loop over all available server variables produces just the following: _SERVER[DOCUMENT_ROOT] _SERVER[HTTP_HOST] _SERVER[HTTP_COOKIE] _SERVER[REQUEST_URI] _SERVER[REQUEST_METHOD] _SERVER[PHP_SELF] _SERVER[SCRIPT_FILENAME] _SERVER[REQUEST_TIME] _SERVER[argv] _SERVER[argc] REMOTE_* variables are missing and phpinfo() shows no traces of remote host information. Test script: --- Expected result: REMOTE_ADDR is set Actual result: -- REMOTE_ADDR missing -- Edit this bug report at https://bugs.php.net/bug.php?id=55463&edit=1
Bug #55475 [Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1
ID: 55475
Updated by: dmi...@php.net
Reported by:mads at gartneriet dot dk
Summary:is_a() triggers autoloader
Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Before the patch, is_a() didn't accept string as the first argument at all, so
it always returned "false" and never triggered __autoload(). The proposed patch
didn't revert to original behavior. It just disables autoloading and may lead
to wrong result.
class a {}
class b extends a {}
var_dump(is_a("b", "a")); // it was false before 5.3.7, now it's true
I would say that the old behaviour was wrong, especially because "instanceof"
and is_subclass_of() already implemented support for string arguments.
Previous Comments:
[2011-08-22 10:30:19] ka...@php.net
The following patch has been added/updated:
Patch Name: bug55475
Revision: 1314009019
URL:
https://bugs.php.net/patch-display.php?bug=55475&patch=bug55475&revision=1314009019
[2011-08-22 10:29:51] ka...@php.net
Zeev, although the functionality might appear as it should be then we should
not make sudden changes like that in the middle of a stable branch, we should
patch up 5.3 and keep the behaviour in 5.4 if its indeed intended atleast to
comply with previous versions.
The fix for 5.3 is simple, attached
[2011-08-22 10:12:48] z...@php.net
Discussed with Dmitry, the current functionality appears to be correct.
is_a('foo', 'bar') *can* be true even if class foo isn't loaded, and we'll only
know that if we try to load 'foo'.
This is different from is_a($obj, 'non_existent_class'), which we can resolve
as
'false' in case non_existent_class isn't loaded without trying to load it
(there
can't be an instance of a class that doesn't exist).
[2011-08-22 09:15:23] col...@php.net
1) The underlying implementation is shared between is_a and is_subclass_of.
2) Previously, strings as first argument was not permitted by is_a but
was for is_subclass_of,
3) is_subclass_of always triggered autoload in such cases.
4) Following a fix from Dmitry, the underlying implementation now
allows a string as first argument for is_a as well.
Conclusion: it is now consistent, but if you wrongly used is_a with a
string before, it now triggers autoload because it actually accepts
it.
[2011-08-22 08:57:32] konstantin dot leboev at gmail dot com
I guess it's not a bug. The first argument can be a class name, what will be
loaded only on calling this function.
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
https://bugs.php.net/bug.php?id=55475
--
Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55473 [Ana->Csd]: mysql_pconnect leaks file descriptors on reconnect
Edit report at https://bugs.php.net/bug.php?id=55473&edit=1 ID: 55473 Updated by: larue...@php.net Reported by:littlesavage at rambler dot ru Summary:mysql_pconnect leaks file descriptors on reconnect -Status: Analyzed +Status: Closed Type: Bug Package:MySQL related PHP Version:5.3.7 -Assigned To: +Assigned To:andrey Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2011-08-22 10:42:35] and...@php.net Automatic comment from SVN on behalf of andrey Revision: http://svn.php.net/viewvc/?view=revision&revision=315270 Log: Fix Bug #55473 mysql_pconnect leaks file descriptors on reconnect The fix is for now in 5_4 and trunk, to be merged into 5_3 after 5.3.8 is packaged (expected today). The test case goes to all branches [2011-08-22 09:01:22] larue...@php.net and the reason for why this cleanup cound not be done in dtor, is that in dtor, it also clean the content, option, which should not free at that memont, and that is not a dtor time in theory. [2011-08-22 08:35:23] larue...@php.net I found this is due to, when doing a reconnect, mysqlnd_connect didn't free the stream. I have submitted a patch, but need georg&andrey&ulf to review first.. [2011-08-22 08:33:34] larue...@php.net The following patch has been added/updated: Patch Name: Bug55473.diff Revision: 1314002014 URL: https://bugs.php.net/patch-display.php?bug=55473&patch=Bug55473.diff&revision=1314002014 [2011-08-22 06:20:46] littlesavage at rambler dot ru I have found this bug on Debian squeeze (x86_64), php PHP 5.3.6-6~dotdeb.1 with Suhosin-Patch, mysql 5.1.58. Then i repeat it on FreeBSD 9, php 5.3.7 with Suhosin-Patch, mysql 5.5.12. On FreeBSD i have found that this bug reproducable only when i use mysqlnd native driver. Everything work as expected with standart mysql driver. 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 https://bugs.php.net/bug.php?id=55473 -- Edit this bug report at https://bugs.php.net/bug.php?id=55473&edit=1
Bug #55475 [PATCH]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1
ID: 55475
Patch added by: ka...@php.net
Reported by:mads at gartneriet dot dk
Summary:is_a() triggers autoloader
Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug55475
Revision: 1314009019
URL:
https://bugs.php.net/patch-display.php?bug=55475&patch=bug55475&revision=1314009019
Previous Comments:
[2011-08-22 10:29:51] ka...@php.net
Zeev, although the functionality might appear as it should be then we should
not make sudden changes like that in the middle of a stable branch, we should
patch up 5.3 and keep the behaviour in 5.4 if its indeed intended atleast to
comply with previous versions.
The fix for 5.3 is simple, attached
[2011-08-22 10:12:48] z...@php.net
Discussed with Dmitry, the current functionality appears to be correct.
is_a('foo', 'bar') *can* be true even if class foo isn't loaded, and we'll only
know that if we try to load 'foo'.
This is different from is_a($obj, 'non_existent_class'), which we can resolve
as
'false' in case non_existent_class isn't loaded without trying to load it
(there
can't be an instance of a class that doesn't exist).
[2011-08-22 09:15:23] col...@php.net
1) The underlying implementation is shared between is_a and is_subclass_of.
2) Previously, strings as first argument was not permitted by is_a but
was for is_subclass_of,
3) is_subclass_of always triggered autoload in such cases.
4) Following a fix from Dmitry, the underlying implementation now
allows a string as first argument for is_a as well.
Conclusion: it is now consistent, but if you wrongly used is_a with a
string before, it now triggers autoload because it actually accepts
it.
[2011-08-22 08:57:32] konstantin dot leboev at gmail dot com
I guess it's not a bug. The first argument can be a class name, what will be
loaded only on calling this function.
[2011-08-22 08:19:04] paj...@php.net
Related to change for the #53727 fix.
http://svn.php.net/viewvc/php/php-
src/branches/PHP_5_3/Zend/zend_builtin_functions.c?r1=307522&r2=312904
Assigned to Dmitry
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
https://bugs.php.net/bug.php?id=55475
--
Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55475 [Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1
ID: 55475
Updated by: ka...@php.net
Reported by:mads at gartneriet dot dk
Summary:is_a() triggers autoloader
Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Zeev, although the functionality might appear as it should be then we should
not make sudden changes like that in the middle of a stable branch, we should
patch up 5.3 and keep the behaviour in 5.4 if its indeed intended atleast to
comply with previous versions.
The fix for 5.3 is simple, attached
Previous Comments:
[2011-08-22 10:12:48] z...@php.net
Discussed with Dmitry, the current functionality appears to be correct.
is_a('foo', 'bar') *can* be true even if class foo isn't loaded, and we'll only
know that if we try to load 'foo'.
This is different from is_a($obj, 'non_existent_class'), which we can resolve
as
'false' in case non_existent_class isn't loaded without trying to load it
(there
can't be an instance of a class that doesn't exist).
[2011-08-22 09:15:23] col...@php.net
1) The underlying implementation is shared between is_a and is_subclass_of.
2) Previously, strings as first argument was not permitted by is_a but
was for is_subclass_of,
3) is_subclass_of always triggered autoload in such cases.
4) Following a fix from Dmitry, the underlying implementation now
allows a string as first argument for is_a as well.
Conclusion: it is now consistent, but if you wrongly used is_a with a
string before, it now triggers autoload because it actually accepts
it.
[2011-08-22 08:57:32] konstantin dot leboev at gmail dot com
I guess it's not a bug. The first argument can be a class name, what will be
loaded only on calling this function.
[2011-08-22 08:19:04] paj...@php.net
Related to change for the #53727 fix.
http://svn.php.net/viewvc/php/php-
src/branches/PHP_5_3/Zend/zend_builtin_functions.c?r1=307522&r2=312904
Assigned to Dmitry
[2011-08-22 08:16:02] mads at gartneriet dot dk
Description:
When calling is_a() with a first argument that is not an object, then
__autoload() is triggered:
Test script:
---
Expected result:
bool(false)
bool(false)
Actual result:
--
Would load: test
bool(false)
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55475 [Com]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1
ID: 55475
Comment by: z...@php.net
Reported by:mads at gartneriet dot dk
Summary:is_a() triggers autoloader
Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Discussed with Dmitry, the current functionality appears to be correct.
is_a('foo', 'bar') *can* be true even if class foo isn't loaded, and we'll only
know that if we try to load 'foo'.
This is different from is_a($obj, 'non_existent_class'), which we can resolve
as
'false' in case non_existent_class isn't loaded without trying to load it
(there
can't be an instance of a class that doesn't exist).
Previous Comments:
[2011-08-22 09:15:23] col...@php.net
1) The underlying implementation is shared between is_a and is_subclass_of.
2) Previously, strings as first argument was not permitted by is_a but
was for is_subclass_of,
3) is_subclass_of always triggered autoload in such cases.
4) Following a fix from Dmitry, the underlying implementation now
allows a string as first argument for is_a as well.
Conclusion: it is now consistent, but if you wrongly used is_a with a
string before, it now triggers autoload because it actually accepts
it.
[2011-08-22 08:57:32] konstantin dot leboev at gmail dot com
I guess it's not a bug. The first argument can be a class name, what will be
loaded only on calling this function.
[2011-08-22 08:19:04] paj...@php.net
Related to change for the #53727 fix.
http://svn.php.net/viewvc/php/php-
src/branches/PHP_5_3/Zend/zend_builtin_functions.c?r1=307522&r2=312904
Assigned to Dmitry
[2011-08-22 08:16:02] mads at gartneriet dot dk
Description:
When calling is_a() with a first argument that is not an object, then
__autoload() is triggered:
Test script:
---
Expected result:
bool(false)
bool(false)
Actual result:
--
Would load: test
bool(false)
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55475 [Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1 ID: 55475 Updated by: col...@php.net Reported by:mads at gartneriet dot dk Summary:is_a() triggers autoloader Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.3.7 Assigned To:dmitry Block user comment: N Private report: N New Comment: 1) The underlying implementation is shared between is_a and is_subclass_of. 2) Previously, strings as first argument was not permitted by is_a but was for is_subclass_of, 3) is_subclass_of always triggered autoload in such cases. 4) Following a fix from Dmitry, the underlying implementation now allows a string as first argument for is_a as well. Conclusion: it is now consistent, but if you wrongly used is_a with a string before, it now triggers autoload because it actually accepts it. Previous Comments: [2011-08-22 08:57:32] konstantin dot leboev at gmail dot com I guess it's not a bug. The first argument can be a class name, what will be loaded only on calling this function. [2011-08-22 08:19:04] paj...@php.net Related to change for the #53727 fix. http://svn.php.net/viewvc/php/php- src/branches/PHP_5_3/Zend/zend_builtin_functions.c?r1=307522&r2=312904 Assigned to Dmitry [2011-08-22 08:16:02] mads at gartneriet dot dk Description: When calling is_a() with a first argument that is not an object, then __autoload() is triggered: Test script: --- Expected result: bool(false) bool(false) Actual result: -- Would load: test bool(false) bool(false) -- Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55473 [Com]: mysql_pconnect leaks file descriptors on reconnect
Edit report at https://bugs.php.net/bug.php?id=55473&edit=1 ID: 55473 Comment by: larue...@php.net Reported by:littlesavage at rambler dot ru Summary:mysql_pconnect leaks file descriptors on reconnect Status: Analyzed Type: Bug Package:MySQL related PHP Version:5.3.7 Block user comment: N Private report: N New Comment: and the reason for why this cleanup cound not be done in dtor, is that in dtor, it also clean the content, option, which should not free at that memont, and that is not a dtor time in theory. Previous Comments: [2011-08-22 08:35:23] larue...@php.net I found this is due to, when doing a reconnect, mysqlnd_connect didn't free the stream. I have submitted a patch, but need georg&andrey&ulf to review first.. [2011-08-22 08:33:34] larue...@php.net The following patch has been added/updated: Patch Name: Bug55473.diff Revision: 1314002014 URL: https://bugs.php.net/patch-display.php?bug=55473&patch=Bug55473.diff&revision=1314002014 [2011-08-22 06:20:46] littlesavage at rambler dot ru I have found this bug on Debian squeeze (x86_64), php PHP 5.3.6-6~dotdeb.1 with Suhosin-Patch, mysql 5.1.58. Then i repeat it on FreeBSD 9, php 5.3.7 with Suhosin-Patch, mysql 5.5.12. On FreeBSD i have found that this bug reproducable only when i use mysqlnd native driver. Everything work as expected with standart mysql driver. [2011-08-22 03:05:27] larue...@php.net I can't reproduce this bug in PHP-5.3.7 on Linux Redhat(64-bit). What's your OS type? [2011-08-21 10:52:44] littlesavage at rambler dot ru Description: Whem Mysql closes created by mysql_pconnect() peristent connection, file descriptor lefts opened and is never reused. I have a server that stops working due to opened file descriptors limit. Test script: --- Expected result: $ php ./test.php reconnect OK. opened files: 76 reconnect OK. opened files: 76 reconnect OK. opened files: 76 reconnect OK. opened files: 76 ... Actual result: -- $ php ./test.php reconnect OK. opened files: 76 reconnect OK. opened files: 77 reconnect OK. opened files: 78 reconnect OK. opened files: 79 ... -- Edit this bug report at https://bugs.php.net/bug.php?id=55473&edit=1
Bug #55475 [Com]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1 ID: 55475 Comment by: konstantin dot leboev at gmail dot com Reported by:mads at gartneriet dot dk Summary:is_a() triggers autoloader Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.3.7 Assigned To:dmitry Block user comment: N Private report: N New Comment: I guess it's not a bug. The first argument can be a class name, what will be loaded only on calling this function. Previous Comments: [2011-08-22 08:19:04] paj...@php.net Related to change for the #53727 fix. http://svn.php.net/viewvc/php/php- src/branches/PHP_5_3/Zend/zend_builtin_functions.c?r1=307522&r2=312904 Assigned to Dmitry [2011-08-22 08:16:02] mads at gartneriet dot dk Description: When calling is_a() with a first argument that is not an object, then __autoload() is triggered: Test script: --- Expected result: bool(false) bool(false) Actual result: -- Would load: test bool(false) bool(false) -- Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55473 [Opn->Ana]: mysql_pconnect leaks file descriptors on reconnect
Edit report at https://bugs.php.net/bug.php?id=55473&edit=1 ID: 55473 Updated by: larue...@php.net Reported by:littlesavage at rambler dot ru Summary:mysql_pconnect leaks file descriptors on reconnect -Status: Open +Status: Analyzed Type: Bug Package:MySQL related PHP Version:5.3.7 Block user comment: N Private report: N Previous Comments: [2011-08-22 08:35:23] larue...@php.net I found this is due to, when doing a reconnect, mysqlnd_connect didn't free the stream. I have submitted a patch, but need georg&andrey&ulf to review first.. [2011-08-22 08:33:34] larue...@php.net The following patch has been added/updated: Patch Name: Bug55473.diff Revision: 1314002014 URL: https://bugs.php.net/patch-display.php?bug=55473&patch=Bug55473.diff&revision=1314002014 [2011-08-22 06:20:46] littlesavage at rambler dot ru I have found this bug on Debian squeeze (x86_64), php PHP 5.3.6-6~dotdeb.1 with Suhosin-Patch, mysql 5.1.58. Then i repeat it on FreeBSD 9, php 5.3.7 with Suhosin-Patch, mysql 5.5.12. On FreeBSD i have found that this bug reproducable only when i use mysqlnd native driver. Everything work as expected with standart mysql driver. [2011-08-22 03:05:27] larue...@php.net I can't reproduce this bug in PHP-5.3.7 on Linux Redhat(64-bit). What's your OS type? [2011-08-21 10:52:44] littlesavage at rambler dot ru Description: Whem Mysql closes created by mysql_pconnect() peristent connection, file descriptor lefts opened and is never reused. I have a server that stops working due to opened file descriptors limit. Test script: --- Expected result: $ php ./test.php reconnect OK. opened files: 76 reconnect OK. opened files: 76 reconnect OK. opened files: 76 reconnect OK. opened files: 76 ... Actual result: -- $ php ./test.php reconnect OK. opened files: 76 reconnect OK. opened files: 77 reconnect OK. opened files: 78 reconnect OK. opened files: 79 ... -- Edit this bug report at https://bugs.php.net/bug.php?id=55473&edit=1
Bug #55473 [Com]: mysql_pconnect leaks file descriptors on reconnect
Edit report at https://bugs.php.net/bug.php?id=55473&edit=1 ID: 55473 Comment by: larue...@php.net Reported by:littlesavage at rambler dot ru Summary:mysql_pconnect leaks file descriptors on reconnect Status: Open Type: Bug Package:MySQL related PHP Version:5.3.7 Block user comment: N Private report: N New Comment: I found this is due to, when doing a reconnect, mysqlnd_connect didn't free the stream. I have submitted a patch, but need georg&andrey&ulf to review first.. Previous Comments: [2011-08-22 08:33:34] larue...@php.net The following patch has been added/updated: Patch Name: Bug55473.diff Revision: 1314002014 URL: https://bugs.php.net/patch-display.php?bug=55473&patch=Bug55473.diff&revision=1314002014 [2011-08-22 06:20:46] littlesavage at rambler dot ru I have found this bug on Debian squeeze (x86_64), php PHP 5.3.6-6~dotdeb.1 with Suhosin-Patch, mysql 5.1.58. Then i repeat it on FreeBSD 9, php 5.3.7 with Suhosin-Patch, mysql 5.5.12. On FreeBSD i have found that this bug reproducable only when i use mysqlnd native driver. Everything work as expected with standart mysql driver. [2011-08-22 03:05:27] larue...@php.net I can't reproduce this bug in PHP-5.3.7 on Linux Redhat(64-bit). What's your OS type? [2011-08-21 10:52:44] littlesavage at rambler dot ru Description: Whem Mysql closes created by mysql_pconnect() peristent connection, file descriptor lefts opened and is never reused. I have a server that stops working due to opened file descriptors limit. Test script: --- Expected result: $ php ./test.php reconnect OK. opened files: 76 reconnect OK. opened files: 76 reconnect OK. opened files: 76 reconnect OK. opened files: 76 ... Actual result: -- $ php ./test.php reconnect OK. opened files: 76 reconnect OK. opened files: 77 reconnect OK. opened files: 78 reconnect OK. opened files: 79 ... -- Edit this bug report at https://bugs.php.net/bug.php?id=55473&edit=1
Bug #55473 [PATCH]: mysql_pconnect leaks file descriptors on reconnect
Edit report at https://bugs.php.net/bug.php?id=55473&edit=1 ID: 55473 Patch added by: larue...@php.net Reported by:littlesavage at rambler dot ru Summary:mysql_pconnect leaks file descriptors on reconnect Status: Open Type: Bug Package:MySQL related PHP Version:5.3.7 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: Bug55473.diff Revision: 1314002014 URL: https://bugs.php.net/patch-display.php?bug=55473&patch=Bug55473.diff&revision=1314002014 Previous Comments: [2011-08-22 06:20:46] littlesavage at rambler dot ru I have found this bug on Debian squeeze (x86_64), php PHP 5.3.6-6~dotdeb.1 with Suhosin-Patch, mysql 5.1.58. Then i repeat it on FreeBSD 9, php 5.3.7 with Suhosin-Patch, mysql 5.5.12. On FreeBSD i have found that this bug reproducable only when i use mysqlnd native driver. Everything work as expected with standart mysql driver. [2011-08-22 03:05:27] larue...@php.net I can't reproduce this bug in PHP-5.3.7 on Linux Redhat(64-bit). What's your OS type? [2011-08-21 10:52:44] littlesavage at rambler dot ru Description: Whem Mysql closes created by mysql_pconnect() peristent connection, file descriptor lefts opened and is never reused. I have a server that stops working due to opened file descriptors limit. Test script: --- Expected result: $ php ./test.php reconnect OK. opened files: 76 reconnect OK. opened files: 76 reconnect OK. opened files: 76 reconnect OK. opened files: 76 ... Actual result: -- $ php ./test.php reconnect OK. opened files: 76 reconnect OK. opened files: 77 reconnect OK. opened files: 78 reconnect OK. opened files: 79 ... -- Edit this bug report at https://bugs.php.net/bug.php?id=55473&edit=1
Bug #55475 [Opn->Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1 ID: 55475 Updated by: paj...@php.net Reported by:mads at gartneriet dot dk Summary:is_a() triggers autoloader -Status: Open +Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.3.7 -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N New Comment: Related to change for the #53727 fix. http://svn.php.net/viewvc/php/php- src/branches/PHP_5_3/Zend/zend_builtin_functions.c?r1=307522&r2=312904 Assigned to Dmitry Previous Comments: [2011-08-22 08:16:02] mads at gartneriet dot dk Description: When calling is_a() with a first argument that is not an object, then __autoload() is triggered: Test script: --- Expected result: bool(false) bool(false) Actual result: -- Would load: test bool(false) bool(false) -- Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
[PHP-BUG] Bug #55475 [NEW]: is_a() triggers autoloader
From: Operating system: PHP version: 5.3.7 Package: Scripting Engine problem Bug Type: Bug Bug description:is_a() triggers autoloader Description: When calling is_a() with a first argument that is not an object, then __autoload() is triggered: Test script: --- Expected result: bool(false) bool(false) Actual result: -- Would load: test bool(false) bool(false) -- Edit bug report at https://bugs.php.net/bug.php?id=55475&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55475&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55475&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55475&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55475&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55475&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55475&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55475&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55475&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55475&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55475&r=support Expected behavior: https://bugs.php.net/fix.php?id=55475&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55475&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55475&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55475&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55475&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55475&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55475&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55475&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55475&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55475&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55475&r=mysqlcfg
