Bug #51192 [Csd]: FILTER_VALIDATE_URL will invalidate a hostname that includes '-'
Edit report at http://bugs.php.net/bug.php?id=51192&edit=1 ID: 51192 Updated by: ahar...@php.net Reported by:solar at azrael dot ws Summary:FILTER_VALIDATE_URL will invalidate a hostname that includes '-' Status: Closed Type: Bug Package:Filter related Operating System: linux PHP Version:5.2.13 Assigned To:aharvey Block user comment: N New Comment: That also works as of 5.3.3 -- I actually own a couple of internationalised domains, so I'm aware of the issue. :) Previous Comments: [2010-08-13 08:39:26] ond...@php.net Please be aware that IDN (PunyCode) url can contain two consecutive hyphens, ie. xn--hkyrky-ptac70bc.cz is OK as well. [2010-04-07 02:43:39] ahar...@php.net The fix for this hasn't been incorporated into any stable releases yet: it came after 5.2.13 was released and 5.3.2 was branched (and far too late in 5.3.2's release cycle to be ported across). Both versions 5.2.14 and 5.3.3 will include this bug fix. [2010-04-06 22:04:34] lupo at e-noise dot com I am experiencing the same behavior with PHP 5.3.2 on Mac OSX. When hostname contains hyphens filter_var() won't validate using the FILTER_VALIDATE_URL filter. The test code posted by "solar at azrael dot ws" produces the following output: string(18) "http://example.com"; bool(false) string(19) "http://exa_mple.com"; [2010-03-03 10:26:58] ahar...@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/. Thank you for the report, and for helping us make PHP better. [2010-03-03 10:25:52] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=295773 Log: Fix for bug #51192 (FILTER_VALIDATE_URL will invalidate a hostname that includes '-'). Original patch by so...@azrael.ws. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51192 -- Edit this bug report at http://bugs.php.net/bug.php?id=51192&edit=1
Bug #51192 [Com]: FILTER_VALIDATE_URL will invalidate a hostname that includes '-'
Edit report at http://bugs.php.net/bug.php?id=51192&edit=1 ID: 51192 Comment by: ond...@php.net Reported by:solar at azrael dot ws Summary:FILTER_VALIDATE_URL will invalidate a hostname that includes '-' Status: Closed Type: Bug Package:Filter related Operating System: linux PHP Version:5.2.13 Assigned To:aharvey Block user comment: N New Comment: Please be aware that IDN (PunyCode) url can contain two consecutive hyphens, ie. xn--hkyrky-ptac70bc.cz is OK as well. Previous Comments: [2010-04-07 02:43:39] ahar...@php.net The fix for this hasn't been incorporated into any stable releases yet: it came after 5.2.13 was released and 5.3.2 was branched (and far too late in 5.3.2's release cycle to be ported across). Both versions 5.2.14 and 5.3.3 will include this bug fix. [2010-04-06 22:04:34] lupo at e-noise dot com I am experiencing the same behavior with PHP 5.3.2 on Mac OSX. When hostname contains hyphens filter_var() won't validate using the FILTER_VALIDATE_URL filter. The test code posted by "solar at azrael dot ws" produces the following output: string(18) "http://example.com"; bool(false) string(19) "http://exa_mple.com"; [2010-03-03 10:26:58] ahar...@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/. Thank you for the report, and for helping us make PHP better. [2010-03-03 10:25:52] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=295773 Log: Fix for bug #51192 (FILTER_VALIDATE_URL will invalidate a hostname that includes '-'). Original patch by so...@azrael.ws. [2010-03-03 09:50:24] ahar...@php.net Yeah, that doesn't quite look right. :) Cheers for the patch; I'll cook up a test script to go with it and commit it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51192 -- Edit this bug report at http://bugs.php.net/bug.php?id=51192&edit=1
[PHP-BUG] Bug #52597 [NEW]: exif is placed before mbstring in php.ini
From: Operating system: Windows Vista 64-bit PHP version: 5.3.3 Package: *Configuration Issues Bug Type: Bug Bug description:exif is placed before mbstring in php.ini Description: php_exif.dll extension can't be loaded, because it depends on php_mbstring.dll. Just uncomminting the corresponding php.ini lines to load both extensions does not work, because in php.ini php_exif.dll is listed earlier than php_mbstring.dll. Simply moving the line that loads php_mbstring.dll before php_exif.dll solves the problem. This affects Windows zip distributions: php-5.3.3-Win32-VC9-x86.zip php-5.3.3-Win32-VC6-x86.zip (Both "php.ini-development" and "php.ini-production" are affected). I could find that this bug was reported multiple times before: #29919, #32552, #32541, #43970. Also #43606 might be related. The impact of this bug: Simply unpacking the PHP zip package on windows and enabling the exif and mbstring extensions does NOT work. Instead it takes half a day of digging through docs and searching internet to find that the order of extensions in php.ini has to be changed. I hope it's easy to fix, and I'm puzzled why this problem is still present after being reported so many times before. -- Edit bug report at http://bugs.php.net/bug.php?id=52597&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52597&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52597&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52597&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52597&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52597&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52597&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52597&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52597&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52597&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52597&r=support Expected behavior: http://bugs.php.net/fix.php?id=52597&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52597&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52597&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52597&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52597&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52597&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52597&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52597&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52597&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52597&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52597&r=mysqlcfg
Bug #52590 [Opn->Fbk]: Hang on
Edit report at http://bugs.php.net/bug.php?id=52590&edit=1 ID: 52590 Updated by: ahar...@php.net Reported by:qiq9 at eloy dot serralaban dot com dot ar Summary:Hang on -Status: Open +Status: Feedback Type: Bug Package:MySQL related Operating System: Windows NT 5.1 b. 2600 SP3 i586 PHP Version:5.3.3 Block user comment: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2010-08-12 09:41:26] qiq9 at eloy dot serralaban dot com dot ar Description: When can't connect to server (example: firewall) it hangs on. Do not returns of mysql_connect() or others functions (but returns from mysql_error(), mysql_get_client_info() and others). mysql_get_client_info() returns: mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 $ php_info() returns: System Windows NT PCC 5.1 build 2600 (Windows XP Professional Service Pack 3) i586 Build Date Jul 21 2010 20:00:47 CompilerMSVC6 (Visual C++ 6.0) Architecturex86 Configure Command cscript /nologo configure.js "--enable-snapshot-build" "--disable-isapi" "--enable-debug-pack" "--disable-isapi" "--without-mssql" "--without-pdo-mssql" "--without-pi3web" "--with-pdo-oci=D:\php-sdk\oracle\instantclient10\sdk,shared" "--with-oci8=D:\php-sdk\oracle\instantclient10\sdk,shared" "--with-oci8-11g=D:\php-sdk\oracle\instantclient11\sdk,shared" "--enable-object-out-dir=../obj/" "--enable-com-dotnet" "--with-mcrypt=static" Server API Apache 2.0 Handler Virtual Directory Support enabled Configuration File (php.ini) Path C:\WIN.0 Loaded Configuration File C:\Progs\Internet\Servidor\PHP\php.ini Scan this dir for additional .ini files (none) Additional .ini files parsed(none) PHP API 20090626 PHP Extension 20090626 Zend Extension 220090626 Zend Extension BuildAPI220090626,TS,VC6 PHP Extension Build API20090626,TS,VC6 Debug Build no Thread Safety enabled Zend Memory Manager enabled Zend Multibyte Support disabled IPv6 Supportenabled Registered PHP Streams php, file, glob, data, http, ftp, zip, compress.zlib, compress.bzip2, phar Registered Stream Socket Transports tcp, udp Registered Stream Filters convert.iconv.*, mcrypt.*, mdecrypt.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk, zlib.*, bzip2.* Configuration apache2handler Apache Version Apache/2.2.15 (Win32) PHP/5.3.3 Apache API Version 20051115 Server Administrator[...] Hostname:Port crjt.PCC:0 Max RequestsPer Child: 0 - Keep Alive: on - Max Per Connection: 100 TimeoutsConnection: 300 - Keep-Alive: 5 Virtual Server Yes Server Root C:/Progs/Internet/Servidor/Apache Loaded Modules core mod_win32 mpm_winnt http_core mod_so mod_actions mod_alias mod_asis mod_auth_basic mod_authn_default mod_authn_file mod_authz_default mod_authz_groupfile mod_authz_host mod_authz_user mod_autoindex mod_cgi mod_dir mod_env mod_include mod_isapi mod_log_config mod_mime mod_negotiation mod_setenvif mod_php5 Directive Local Value Master Value engine 1 1 last_modified 0 0 xbithack0 0 Apache Environment VariableValue HTTP_HOST crjt.pcc HTTP_USER_AGENT Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729) HTTP_ACCEPT text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HTTP_ACCEPT_LANGUAGEes-es,es;q=0.8,en-us;q=0.5,en;q=0.3 HTTP_ACCEPT_ENCODINGgzip,deflate HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_KEEP_ALIVE 115 HTTP_CONNECTION keep-alive PATH C:\WIN.0\system32;C:\WIN.0;C:\WIN.0\System32\Wbem;C:\Progs\Ãtil\doxygen\bin SystemRoot C:\WIN.0 COMSPEC C:\WIN.0\system32\cmd.exe PATHEXT .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH WINDIR C:\WIN.0 SERVER_SIGNATUREno value SERVER_SOFTWARE Apache/2.2.15 (Win32) PHP/5.3.3 SERVER_NAME crjt.pcc SERVER_ADDR 127.0.0.1 SERVER_PORT 80 REMOTE_ADDR 127.0.0.1 DOCUMENT_ROOT C:/Usuarios/Reloj.PCC/Mis documentos/My Dropbox/CRJT/nuevo SERVER_ADMIN[...] SCRIPT_FILENAME C:/Usuarios/Reloj.PCC/Mis documentos/My Dropbox/CRJT/nuevo/phpinfo.php REMOTE_PORT 3794 GATEWAY_INTERFACE
Bug #52592 [Opn->Bgs]: mb_ereg_replace and the Greek capital Pi
Edit report at http://bugs.php.net/bug.php?id=52592&edit=1 ID: 52592 Updated by: ahar...@php.net Reported by:pj at ezgr dot net Summary:mb_ereg_replace and the Greek capital Pi -Status: Open +Status: Bogus Type: Bug Package:mbstring related Operating System: Centos 5.5 x64 PHP Version:5.2.14 Block user comment: N New Comment: You need to also call mb_regex_encoding('UTF-8'); before using a UTF-8 regular expression. Previous Comments: [2010-08-12 14:36:15] pj at ezgr dot net Description: PHP: 5.2.14, Apache 2.2.15, mod_php While \s is supposed to match all whitespace, the greek unicode letter Pi (Î ) whose code is 0xCEA0 is matched too and if replaced with something, it's stripped of its second byte (0xA0). Test script: --- Expected result: Î Î Î ! Î __Î __Î ! %CE%A0++%CE%A0++%CE%A0%21 %CE%A0__%CE%A0__%CE%A0%21 Actual result: -- Î Î Î ! [non printable character]_[non printable character]_[non printable character]! %CE%A0++%CE%A0++%CE%A0%21 %CE_%CE_%CE_%21 -- Edit this bug report at http://bugs.php.net/bug.php?id=52592&edit=1
Req #47383 [Opn->Bgs]: override declaration with non type hinted params should allow type hinting
Edit report at http://bugs.php.net/bug.php?id=47383&edit=1 ID: 47383 Updated by: s...@php.net Reported by:info at netmosfera dot it Summary:override declaration with non type hinted params should allow type hinting -Status: Open +Status: Bogus Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: * PHP Version:5.3.0beta1 Block user comment: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Method arguments are supposed to be contravariant, see: http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29#Need_for_covariant_argument_types.3F Previous Comments: [2009-02-13 21:15:49] info at netmosfera dot it better explanation: class a { function a(File $x){echo get_class($x);} } class b extends a { function a(ImageFile $x){echo get_class($x);} } this obviously works! now, if mixed means "accepts everything" class a { function a(Mixed $x){echo get_class($x);} } i should be able to override it: class b extends a { function a(File $x){echo get_class($x);} } no? [2009-02-13 20:45:43] info at netmosfera dot it Description: hello i think that non-type-hinted arguments (mixed values): class a { function test([mixed] $argument){} } should allow type hinting in child classes class b extends a { function test(ImageFile $argument){} } Reproduce code: --- "mixed" is a general type... means "everything" but if i want to build an ArrayObject object with one-only type i cannot do this [internal] class ArrayObject implements ArrayAccess { function offsetSet($o, [mixed] $value) {} } class ImageList extends ArrayObject { function offsetSet($o, Image $imageObject) // fatal error! {} } Actual result: -- Fatal error: Declaration of ImageList::offsetSet() must be compatible with that of ArrayAccess::offsetSet() in xx on line 8 thank you -- Edit this bug report at http://bugs.php.net/bug.php?id=47383&edit=1
Bug #49177 [Ver->Bgs]: include() causes strict erros when including overloading methods (PHP_5_2 only!)
Edit report at http://bugs.php.net/bug.php?id=49177&edit=1 ID: 49177 Updated by: s...@php.net Reported by:ss at zornig dot dk Summary:include() causes strict erros when including overloading methods (PHP_5_2 only!) -Status: Verified +Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: * PHP Version:5.* Block user comment: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php You example restricts first parameter from ObjParent to ObjChild. making child function accept only subset of arguments that parent function accepts. This is a violation of LSP, of which the warning warns. Previous Comments: [2010-04-20 13:40:29] ss at zornig dot dk I have found a similar error in 5.3.2 [2010-04-20 13:39:38] ss at zornig dot dk Description: This works in 5.3.2 however, I have found a similar error. Reproduce code: --- test.php: obj.php: Expected result: This should be without any errors as i would if the test.php looks like this: Actual result: -- Strict Standards: Declaration of ObjChild::set() should be compatible with that of ObjParent::set() in /usr/home/webroot/dumpsite/bug/obj.php on line 4 [2009-08-06 12:03:08] ss at zornig dot dk Description: When overloading a method, changing a parameter to accept a default value E_STRICT error is triggered. This however only happens if the object declaration is loading using include, not if the declaration is in the file called. Reproduce code: --- test.php: obj.php: Expected result: This should be without any errors as i would if the test.php looks like this: Actual result: -- Strict Standards: Declaration of ObjChild::set() should be compatible with that of ObjParent::set() in /home/webroot/dumpsite/obj.php on line 8 -- Edit this bug report at http://bugs.php.net/bug.php?id=49177&edit=1
[PHP-BUG] Bug #52596 [NEW]: SOAP result empty NULL lastResponse filled
From: Operating system: Linux PHP version: 5.2.14 Package: SOAP related Bug Type: Bug Bug description:SOAP result empty NULL lastResponse filled Description: I have a script which makes a WSDL SOAP call and the result is empty. No error. The __getLastResponse() is filled. Test script: --- please take a look at: http://files.it-gnoth.de/software/source/php/soap_sample/wsdl-native.php this directory you can browse: http://files.it-gnoth.de/software/source/php/soap_sample with right mouse click it should be possible to download the file. auth token: 49fb1f08bfd34d2b92949af0f9b9bb61 client id: 225 method: get status: active -- Edit bug report at http://bugs.php.net/bug.php?id=52596&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52596&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52596&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52596&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52596&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52596&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52596&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52596&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52596&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52596&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52596&r=support Expected behavior: http://bugs.php.net/fix.php?id=52596&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52596&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52596&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52596&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52596&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52596&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52596&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52596&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52596&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52596&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52596&r=mysqlcfg
Bug #52368 [Com]: crash in preg_replace_impl
Edit report at http://bugs.php.net/bug.php?id=52368&edit=1 ID: 52368 Comment by: cobexer at gmail dot com Reported by:cobexer at gmail dot com Summary:crash in preg_replace_impl Status: Feedback Type: Bug Package:PCRE related Operating System: Debian Lenny (5.0.5) PHP Version:5.2.13 Block user comment: N New Comment: I did a quick test today using http://snaps.php.net/php5.3-latest.tar.gz (from yesterday) does not crash(as expected since the problem didn't exist there anyway). however using http://snaps.php.net/php5.2-latest.tar.gz (from yesterday) still crashes on the same line as before. (tested on i586 openSuSE 11.4(Factory)) regards cobexer Previous Comments: [2010-08-09 03:19:31] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-07-30 21:24:40] cobexer at gmail dot com hmm that crash is hard to nail down, it doesn't crash on all of my computers, therefore i did the following: * created crashing test script (currently ~150 Lines) * compiled php 5.2.14 (with -O0) (in /php) on a i586 openSUSE Factory(a bit newer than 11.3) * created a core dump * tar'gz ed it together and uploaded that to http://gomorrah-online.de/php-5.2.14-crash.tar.gz important contents: scrash.php : the php script with the code to crash (run with php -e) scrash.php.log : the output of the script till it crashed php-bt.txt : output of "bt" and "bt full" core : the coredump itself maybe that helps already, regards cobexer [2010-07-18 19:39:03] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-07-17 23:48:30] cobexer at gmail dot com Description: the crash occuring is most likely related to very high integer/double values(>10M) being inserted in a long string(~20K). the problem does not occur on PHP5.3.something so it might be a simple backport :). unless somebody can tell me how i get more information out of the crashing process this is all i have (trying to print local variables of the crashing function results in: (gdb) p **regex Cannot access memory at address 0x686f72393438343e os similar the regular expression involved is most likely: '/\{([A-Z0-9_]*)(?:\|(?P[A-Z0-9_]+))?\}/' executed by preg_replace_callback, where the callback is an array('class_name', 'some_private_function') if required i try to build a small test script and attach that - but i guess its not required. probably related to http://bugs.php.net/bug.php?id=39016 reproducible: always Test script: --- Expected result: no php crash correctly replaced string Actual result: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f877c078750 (LWP 6259)] preg_replace_impl (ht=5, return_value=0x12a8a90, return_value_ptr=0x137c970, this_ptr=0xb9e82fb02f28a27c, return_value_used=0, is_callable_replace=0 '\0') at /usr/src/php5/source/php5-5.2.13/Zend/zend_variables.h:32 warning: Source file is more recent than executable. 32 if (zvalue->type <= IS_BOOL) { (gdb) bt #0 preg_replace_impl (ht=5, return_value=0x12a8a90, return_value_ptr=0x137c970, this_ptr=0xb9e82fb02f28a27c, return_value_used=0, is_callable_replace=0 '\0') at /usr/src/php5/source/php5-5.2.13/Zend/zend_variables.h:32 #1 0x7f8774cef3cd in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff5410) at /usr/src/php5/source/php5-5.2.13/Zend/zend_vm_execute.h:200 #2 0x7f8774cd8134 in execute (op_array=0xf02040) at /usr/src/php5/source/php5-5.2.13/Zend/zend_vm_execute.h:92 #3 0x7f8774ceecde in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff5760) at /usr/src/php5/source/php5-5.2.13/Zend/zend_vm_execute.h:234 #4 0x7f8774cd8134 in execute (op_array=0xef48b0) at /usr/src/php5/source/php5-5.2.13/Zend/zend_vm_execute.h:92 #5 0x7f8774ceecde in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff5e70) at /usr/src/php5/source/php5-5.2.13/Zend/zend_vm_execute.h:234 #6 0x7f8774cd8134 in execute (op_array=0xf03780) at /usr/src/php5/source/php5-5.2.13/Zend/zend_vm_execute.
Bug #49867 [Com]: spl_autoload crashes when called in write function of custom sessionSaveHandler
Edit report at http://bugs.php.net/bug.php?id=49867&edit=1 ID: 49867 Comment by: iamcraigcampbell at gmail dot com Reported by:nicolas dot lepage at yahoo dot fr Summary:spl_autoload crashes when called in write function of custom sessionSaveHandler Status: No Feedback Type: Bug Package:SPL related Operating System: * PHP Version:5.3.0 Block user comment: N New Comment: Just experienced this issue after upgrading to PHP 5.3.3, APC 3.1.4 on Debian GNU/Linux 4.0. When using the session handler from an instance of a class it would give a fatal error: Fatal error: Undefined class constant... After switching to use static session handler methods there was no longer a fatal error, but it caused a segfault which was traced back to spl_autoload_register(). Tried a bunch of stuff but was able to fix the issue by registering a shutdown function similar to this: register_shutdown_function('shutdown'); function shutdown() { session_write_close(); } Previous Comments: [2010-06-12 23:39:43] zapparov at member dot fsf dot org And one more interesting thing. This Fatal error is thrown (!) after all operations were completed - so Im receiving exactly what I was expecting to receive but with Fatal Error and it's trace appended to it. o_O [2010-06-12 23:34:44] zapparov at member dot fsf dot org Unfortunately not for me. Also, by some reason this problem occurs only on some requests. I'll try to prepare a simple test which will reproduce this issue soonly. [2010-06-12 15:48:06] ras...@php.net Doesn't calling session_write_close() completely solve this issue? [2010-06-12 12:23:24] zapparov at member dot fsf dot org Forgot to say - error occurs wonly when APC is enabled. [2010-06-12 11:24:11] zapparov at member dot fsf dot org Hello, Have exactly the same problem with Zend Framework + Doctrine (they both register own autoloaders). So when APC is enabled - it reproduces same fatal error. I'll try to gather more information about what happens little bit later. My PHP version is 5.3.2 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49867 -- Edit this bug report at http://bugs.php.net/bug.php?id=49867&edit=1
Bug #35090 [Bgs]: file i/o is not buffered
Edit report at http://bugs.php.net/bug.php?id=35090&edit=1 ID: 35090 User updated by:askalski at gmail dot com Reported by:askalski at gmail dot com Summary:file i/o is not buffered Status: Bogus Type: Bug Package:Filesystem function related Operating System: linux -PHP Version:5CVS-2005-11-03 (snap) +PHP Version:5.3.3 Block user comment: N New Comment: I guess that's one way to deal with it. At least then it would be clear to PHP developers that each fwrite() makes a separate system call. Even better would be for PHP to use the C stdio library for file i/o, and take advantage of the buffering it offers by default. Even back in the 1970's when C was created, they had already figured out that buffered I/O was a good thing, and consequently built it into stdio... (I'm surprised to see feedback on a bug ticket that was closed as "Bogus" almost five years ago. Ultimately, this is pretty low on my list of "reasons PHP execution is so painfully slow"; it's just something I spotted when doing an strace to troubleshoot an unrelated issue. That's why I never bothered to pursue it further.) Previous Comments: [2010-08-12 12:59:41] surfchen at gmail dot com So we need to add a note on the documentation say that this function not supported with filesystem wrapper, right? [2005-11-03 23:40:24] askalski at gmail dot com > instead it uses the system's file io buffering function > to set the buffer. Assuming you're talking about setvbuf() and not kernel level write-behind caching, this statement is false. The file is opened by _php_stream_fopen(): fd = open(realpath, open_flags, 0666); (It is never subsequently wrapped with fdopen()) At this point, the stream is not buffered at all. When I later call stream_set_write_buffer(), it hits php_stdiop_set_option(): case PHP_STREAM_OPTION_WRITE_BUFFER: if (data->file == NULL) { return -1; } /* setvbuf happens down here */ Because there is no FILE* handle (data->file), setvbuf() is never called for the stream. One of either the documentation (http://us3.php.net/stream_set_write_buffer) or the PHP source is wrong. [2005-11-03 21:34:16] il...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php PHP does not do any buffering itself, instead it uses the system's file io buffering function to set the buffer. There is already a feature request open to enable in-php buffering. [2005-11-03 21:29:08] der...@php.net Can you please answer why this is not a bug Wez? I forgot the reason :) [2005-11-03 19:16:09] askalski at gmail dot com Description: The documentation for stream_set_write_buffer() says that fwrite()s are buffered at 8K by default. In reality, it does not buffer at all. Any attempt to call stream_set_write_buffer() on a regular file handle results in failure. Reproduce code: --- $fh = fopen("asdf", "w"); // write some data using the default buffering for ($i = 0; $i < 5; $i++) fwrite($fh, "test"); // demonstrate that stream_set_write_buffer fails $n = stream_set_write_buffer($fh, 8192); if ($n != 0) echo "stream_set_write_buffer failed\n"; // write some more data to demonstrate the failure for ($i = 0; $i < 5; $i++) fwrite($fh, "again"); fclose($fh); Expected result: PHP should buffer its I/O, and strace should log a single write(). stream_set_write_buffer() should not fail on regular files. Actual result: -- Output: stream_set_write_buffer failed Abridged strace output: open("/tmp/php5-200511031730/asdf", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 lseek(3, 0, SEEK_CUR) = 0 write(3, "test", 4) = 4 write(3, "test", 4) = 4 write(3, "test", 4) = 4 write(3, "test", 4) = 4 write(3, "test", 4) = 4 write(1, "stream_set_write_buffer failed\n", 31) = 31 write(3, "again", 5)= 5 write(3, "again", 5)= 5 write(3, "again", 5)= 5 write(3, "again", 5)= 5 write(3, "again", 5)= 5 close(3)= 0
Bug #52594 [Opn->Fbk]: option -c in php cli
Edit report at http://bugs.php.net/bug.php?id=52594&edit=1 ID: 52594 Updated by: johan...@php.net Reported by:bernardo at datamex dot com dot br Summary:option -c in php cli -Status: Open +Status: Feedback Type: Bug Package:CGI related Operating System: Feebsd PHP Version:5.3.3 Block user comment: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I can't reproduce it. Are you using our sources or patches from FreeBSD? Previous Comments: [2010-08-12 17:59:06] bernardo at datamex dot com dot br Description: in php 5.2 php -c option could include a space out-ceo name. ini file, already in PHP 5.3 does not work. php 5.2 php -c teste.ini or php -cteste.ini Loaded Configuration File => teste.ini php 5.3 php -cteste.ini Loaded Configuration File => teste.ini php -c teste.ini Loaded Configuration File => (none) -- Edit this bug report at http://bugs.php.net/bug.php?id=52594&edit=1
[PHP-BUG] Bug #52594 [NEW]: option -c in php cli
From: Operating system: Feebsd PHP version: 5.3.3 Package: CGI related Bug Type: Bug Bug description:option -c in php cli Description: in php 5.2 php -c option could include a space out-ceo name. ini file, already in PHP 5.3 does not work. php 5.2 php -c teste.ini or php -cteste.ini Loaded Configuration File => teste.ini php 5.3 php -cteste.ini Loaded Configuration File => teste.ini php -c teste.ini Loaded Configuration File => (none) -- Edit bug report at http://bugs.php.net/bug.php?id=52594&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52594&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52594&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52594&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52594&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52594&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52594&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52594&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52594&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52594&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52594&r=support Expected behavior: http://bugs.php.net/fix.php?id=52594&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52594&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52594&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52594&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52594&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52594&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52594&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52594&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52594&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52594&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52594&r=mysqlcfg
Bug #49383 [Bgs]: Lots of empty fstat() calls slow performance
Edit report at http://bugs.php.net/bug.php?id=49383&edit=1 ID: 49383 Updated by: ras...@php.net Reported by:olga at metacafe dot com Summary:Lots of empty fstat() calls slow performance Status: Bogus Type: Bug Package:Performance problem Operating System: Red Hat 3.4.6-10 PHP Version:5.3, 6 Block user comment: N New Comment: The reason open_basedir affects this is because for security reasons we can't enable the stat cache when open_basedir is enabled which will also affect stats after the file is opened since it isn't the open_basedir check itself causing the stat but the fact that the open_basedir feature forces the stat cache to be disabled. The main thing that changed between 5.2.x and 5.3.x with respect to stats is that we rewrote the stat cache to be more efficient. It now does intra-path caching of realpath() lookups as opposed to just caching the return of the realpath() call, but it doesn't sound like this is the issue here. One thing you can try is to compile PHP without phar support. ./configure -- disable-phar and see if that changes things. Beyond that you would need to set a gdb breakpoint and get a backtrace of those calls. Generally we are not too concerned about fstat calls since they tend to be extremely fast in most environments. It is the full stat/lstat calls that need to hit the disk that tend to be slow. Previous Comments: [2010-08-12 15:58:41] a dot rogge at solvention dot de First of all: No, we don't use open_basedir or safe_mode or stuff like that. But I still do not understand what this has to do with the issue. The redundant fstat() calls are obviously *not* from open_basedir, because the fstat() calls are done after the file was opened. I run 5.1.6, 5.2.14 and 5.3.2 with the same configuration. For 5.1.6 and 5.2.14 everything looks normally, in 5.3.2 there are suddenly three instead of one fstat() call after opening the file. The calls are identical and adjacent with no other syscalls in between. The two successive calls do not provide any more information than the first one and thus are redundant and useless. This is obviously a performance regression. Do you want to tell me that this is a new feature? [2010-08-12 01:24:32] ras...@php.net Do you have openbase_dir enabled? If so, for security reasons we can't use the stat cache which is going to cause a lot of stats. For a setup with slow stats, I suggest chroot/jail or something along those lines rather than open_basedir to keep users separated. [2010-08-11 20:10:56] a dot rogge at solvention dot de Nobody cares wether or not APC works around the problem. There is obviously a regression from 5.2 to 5.3. Somebody maanged to triple the number of fstat() calls that are done for an include(). Yesterday I "reproduced" the issue on our webcluster. Running the Red Hat provided PHP 5.1.6 (from RHEL 5.5) the loadavg was around 8 for all boxes. Upgrading to PHP 5.3.2 made the loadavg raised to values of 30 or higher. Page load time went from < 1 second to around 30 seconds. The best part is: we did install and configure apc for 5.3.2, but not for 5.1.6 So eventually 5.3.2 *with* APC produces 3 times more load and needs 30 times longer than our ancient 5.1.6 *without* APC. However, I must admit that we have our PHP-files on GFS2 where stat() is traditionally a bit slow. [2010-01-21 23:16:42] ras...@php.net Unable to reproduce under apc. [2009-10-14 11:28:06] olga at metacafe dot com The problem persists. We upgraded APC to the latest version (3.1.3p1). Cache full count is 0, hit ratio is 99.9%. I understand that this shouldn't happen, but there are still 3 fstat() calls per file opened. Here's our APC configuration - maybe you can see if anything is wrong with it? Do you have other versions? apc.cache_by_default1 apc.canonicalize1 apc.coredump_unmap 0 apc.enable_cli 1 apc.enabled 1 apc.file_md50 apc.file_update_protection 2 apc.filters apc.gc_ttl 3600 apc.include_once_override 1 apc.lazy_classes0 apc.lazy_functions 0 apc.max_file_size 1M apc.mmap_file_mask /tmp/apc.IR76ZW apc.num_files_hint 1024 apc.preload_path apc.report_autofilter 0 apc.rfc1867 0 apc.rfc1867_freq0 apc.rfc1867_nameAPC_UPLOAD_PROGRESS apc.rfc1867_prefix upload_ apc.rfc1867_ttl 3600 apc.shm_segments1 apc.shm_size128 apc.stat0 apc.stat_ctime 0 apc.ttl 7200 apc.use_reque
Req #52593 [Opn->Bgs]: Getting scope variables of the caller function
Edit report at http://bugs.php.net/bug.php?id=52593&edit=1 ID: 52593 Updated by: der...@php.net Reported by:hpolthof at gmail dot com Summary:Getting scope variables of the caller function -Status: Open +Status: Bogus Type: Feature/Change Request Package:*General Issues PHP Version:5.2.14 Block user comment: N New Comment: . Previous Comments: [2010-08-12 15:36:33] hpolthof at gmail dot com Multiple levels are in my opinion not necessary, neighter the way of implementation. The scope variables could also be made available thru the backtrace() function. And still have no official support. @dragoonis: I don't know how more specific it can get. get_caller_vars() is a non-existent function. Hence this feature request! [2010-08-12 15:10:27] johan...@php.net Then you also need get_callers_caller_vars() and get_callers_callers_caller_vars() but by definition a function shall be independent from the caller's scope. All required information shall be passed as parameter. [2010-08-12 15:05:21] dragoo...@php.net Please elaborate on "such a function does not exist" with an exact error message. [2010-08-12 14:45:51] hpolthof at gmail dot com Description: In bug #48290 was the function get_caller_vars() suggested. But in that case it was irrelevant. However do I seek such a function. get_defined_vars() returns the vars in the current scope. As do i like to get the variables of the caller routine. This would allow me to use parameters from a subroutine without having to refactor another parameter being get_defined_vars() as this would obviously uglify my code, which would impeach the reason to refactor in the first place. Test script: --- function a() { $test = 'A'; b(); } function b() { $test = 'B'; $vars_local = get_defined_vars(); $vars_caller = get_caller_vars(); echo $vars_caller['test']; // Expexted: A echo $vars_local['test']; // Expected: B } a(); Expected result: A B Actual result: -- such a function does not exist -- Edit this bug report at http://bugs.php.net/bug.php?id=52593&edit=1
Bug #1 [Opn->Bgs]: Apache 1.3b3 + mod_php3 is slow
Edit report at http://bugs.php.net/bug.php?id=1&edit=1 ID: 1 Updated by: johan...@php.net Reported by:rasmus at lerdorf dot on dot ca Summary:Apache 1.3b3 + mod_php3 is slow -Status: Open +Status: Bogus Type: Bug Package:Performance problem Operating System: Solaris 2.5.1 PHP Version:3.0b3 Block user comment: N New Comment: test2 Previous Comments: [2010-08-12 16:04:04] johan...@php.net test [2010-07-26 03:09:03] fel...@php.net test [2010-07-26 03:06:49] fel...@php.net testing [2010-07-25 21:00:15] fel...@php.net . [2010-07-21 17:35:09] ahar...@php.net Test comment. Sorry about the noise. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=1 -- Edit this bug report at http://bugs.php.net/bug.php?id=1&edit=1
Bug #1 [Bgs->Opn]: Apache 1.3b3 + mod_php3 is slow
Edit report at http://bugs.php.net/bug.php?id=1&edit=1 ID: 1 Updated by: johan...@php.net Reported by:rasmus at lerdorf dot on dot ca Summary:Apache 1.3b3 + mod_php3 is slow -Status: Bogus +Status: Open Type: Bug Package:Performance problem Operating System: Solaris 2.5.1 PHP Version:3.0b3 -Block user comment: Y +Block user comment: N New Comment: test Previous Comments: [2010-07-26 03:09:03] fel...@php.net test [2010-07-26 03:06:49] fel...@php.net testing [2010-07-25 21:00:15] fel...@php.net . [2010-07-21 17:35:09] ahar...@php.net Test comment. Sorry about the noise. [2010-07-21 17:34:17] paj...@php.net unassigned The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=1 -- Edit this bug report at http://bugs.php.net/bug.php?id=1&edit=1
Bug #49383 [Com]: Lots of empty fstat() calls slow performance
Edit report at http://bugs.php.net/bug.php?id=49383&edit=1 ID: 49383 Comment by: a dot rogge at solvention dot de Reported by:olga at metacafe dot com Summary:Lots of empty fstat() calls slow performance Status: Bogus Type: Bug Package:Performance problem Operating System: Red Hat 3.4.6-10 PHP Version:5.3, 6 Block user comment: N New Comment: First of all: No, we don't use open_basedir or safe_mode or stuff like that. But I still do not understand what this has to do with the issue. The redundant fstat() calls are obviously *not* from open_basedir, because the fstat() calls are done after the file was opened. I run 5.1.6, 5.2.14 and 5.3.2 with the same configuration. For 5.1.6 and 5.2.14 everything looks normally, in 5.3.2 there are suddenly three instead of one fstat() call after opening the file. The calls are identical and adjacent with no other syscalls in between. The two successive calls do not provide any more information than the first one and thus are redundant and useless. This is obviously a performance regression. Do you want to tell me that this is a new feature? Previous Comments: [2010-08-12 01:24:32] ras...@php.net Do you have openbase_dir enabled? If so, for security reasons we can't use the stat cache which is going to cause a lot of stats. For a setup with slow stats, I suggest chroot/jail or something along those lines rather than open_basedir to keep users separated. [2010-08-11 20:10:56] a dot rogge at solvention dot de Nobody cares wether or not APC works around the problem. There is obviously a regression from 5.2 to 5.3. Somebody maanged to triple the number of fstat() calls that are done for an include(). Yesterday I "reproduced" the issue on our webcluster. Running the Red Hat provided PHP 5.1.6 (from RHEL 5.5) the loadavg was around 8 for all boxes. Upgrading to PHP 5.3.2 made the loadavg raised to values of 30 or higher. Page load time went from < 1 second to around 30 seconds. The best part is: we did install and configure apc for 5.3.2, but not for 5.1.6 So eventually 5.3.2 *with* APC produces 3 times more load and needs 30 times longer than our ancient 5.1.6 *without* APC. However, I must admit that we have our PHP-files on GFS2 where stat() is traditionally a bit slow. [2010-01-21 23:16:42] ras...@php.net Unable to reproduce under apc. [2009-10-14 11:28:06] olga at metacafe dot com The problem persists. We upgraded APC to the latest version (3.1.3p1). Cache full count is 0, hit ratio is 99.9%. I understand that this shouldn't happen, but there are still 3 fstat() calls per file opened. Here's our APC configuration - maybe you can see if anything is wrong with it? Do you have other versions? apc.cache_by_default1 apc.canonicalize1 apc.coredump_unmap 0 apc.enable_cli 1 apc.enabled 1 apc.file_md50 apc.file_update_protection 2 apc.filters apc.gc_ttl 3600 apc.include_once_override 1 apc.lazy_classes0 apc.lazy_functions 0 apc.max_file_size 1M apc.mmap_file_mask /tmp/apc.IR76ZW apc.num_files_hint 1024 apc.preload_path apc.report_autofilter 0 apc.rfc1867 0 apc.rfc1867_freq0 apc.rfc1867_nameAPC_UPLOAD_PROGRESS apc.rfc1867_prefix upload_ apc.rfc1867_ttl 3600 apc.shm_segments1 apc.shm_size128 apc.stat0 apc.stat_ctime 0 apc.ttl 7200 apc.use_request_time1 apc.user_entries_hint 4096 apc.user_ttl7200 apc.write_lock 1 [2009-09-03 16:49:18] ras...@php.net The only time this code is executed if you are running APC is if the script is not cached. So, either your APC setup is not working, you are constantly trashing your cache (check apc.php and look at the cache-full counter), or something else weird is going on. These fstats are coming from compiler which reads the script from disk and compiles it down to opcodes. It is impossible for this code to execute on an APC-cached script because we point the executor directly at the already compiled opcodes in shared memory. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49383 -- Edit this bug report at http://bugs.php.net/bug.php?id=49383&edit=1
Bug #50921 [Com]: '200 OK' HTTP status despite PHP error
Edit report at http://bugs.php.net/bug.php?id=50921&edit=1 ID: 50921 Comment by: tyra3l at gmail dot com Reported by:phpbug at starurl dot com Summary:'200 OK' HTTP status despite PHP error Status: Bogus Type: Bug Package:HTTP related Operating System: * PHP Version:5.2.12 Block user comment: N New Comment: It's seems that this is a known bug in the xdebug, see: http://bugs.xdebug.org/view.php?id=587 but couldn't fix it without making some changes in php itself: "Before I can address this, there need to be some changes in PHP itself. It doesn't expose some required information to extensions yet that I will need." I hope this get fixed soon. Tyrael Previous Comments: [2010-08-12 15:35:41] tyra3l at gmail dot com I can reproduce the problem. I found out, that if I enable xdebug, then I get header 200, if I disable it, then it's 500. Will report it to Derick. Tyrael [2010-03-12 08:37:24] anzenews at volja dot net I am also having huge problems with this - haproxy health checks do not work reliably because of this bug. Please consider reopening it - it is not bogus. PHP doesn't return HTTP error code, even if display_errors is set to 0. One example: This returns an empty page with status code 200: - HTTP/1.1 200 OK DateFri, 12 Mar 2010 07:27:15 GMT Server Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny6 with Suhosin-Patch X-Powered-ByPHP/5.2.6-1+lenny6 VaryAccept-Encoding Content-Encodinggzip Content-Length 20 Keep-Alive timeout=15, max=100 Connection Keep-Alive Content-Typetext/html - Content-Length is 20, probably because of gzip? There are no spaces around PHP block in source code. I have checked phpinfo() and display_errors is set to Off, so there is no error there. Also, I have tried setting it in php.ini - no change. Another problem: parse errors are also not handled correctly (even if display_errors is set to 0 in php.ini). See previous poster's example. Thanks! [2010-02-03 19:03:56] der...@php.net The reason why display errors needs to be turned of, is because displayed errors generate output, and output causes the headers to be send out. I'm afraid we can't do much about this. [2010-02-03 18:01:37] phpbug at starurl dot com Thank you for the swift response Jani. I can confirm that the 500 status code works for the following (runtime error): But fails for parse errors (because the "disply_errors" line doesn't get executed): Firstly, is this dependency really necessary? Just because we have 'display_errors' enabled doesn't mean we want fatal errors to go unlogged and unnoticed because a "200 OK" status is incorrectly returned. Secondly, the majority of PHP developers out there use shared hosting, on which 'display_errors' is normally true and is impossible to change globally - are we saying they're stuck with incorrect HTTP status codes when parse errors occur? The restriction that headers must not already have been sent is of course understandable as it is unavoidable. Not overriding an explicitly set HTTP status code also makes sense. But why not set the status code as "500 Internal Server Error" when any fatal parse/runtime error occurs, regardless of the value of 'display_errors'? This would be consistent with the HTTP spec, which recommends a 5XX response if an error occurs, and is followed by just about every other web server language out there (e.g., ASP, .NET). Many thanks, BJ [2010-02-03 10:06:27] j...@php.net It does happen. It requires that: 1) display_errors = off 2) No headers have been sent yet by the time the error happens 3) Status is 200 at that time. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=50921 -- Edit this bug report at http://bugs.php.net/bug.php?id=50921&edit=1
Req #52593 [Opn]: Getting scope variables of the caller function
Edit report at http://bugs.php.net/bug.php?id=52593&edit=1 ID: 52593 User updated by:hpolthof at gmail dot com Reported by:hpolthof at gmail dot com Summary:Getting scope variables of the caller function Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.2.14 Block user comment: N New Comment: Multiple levels are in my opinion not necessary, neighter the way of implementation. The scope variables could also be made available thru the backtrace() function. And still have no official support. @dragoonis: I don't know how more specific it can get. get_caller_vars() is a non-existent function. Hence this feature request! Previous Comments: [2010-08-12 15:10:27] johan...@php.net Then you also need get_callers_caller_vars() and get_callers_callers_caller_vars() but by definition a function shall be independent from the caller's scope. All required information shall be passed as parameter. [2010-08-12 15:05:21] dragoo...@php.net Please elaborate on "such a function does not exist" with an exact error message. [2010-08-12 14:45:51] hpolthof at gmail dot com Description: In bug #48290 was the function get_caller_vars() suggested. But in that case it was irrelevant. However do I seek such a function. get_defined_vars() returns the vars in the current scope. As do i like to get the variables of the caller routine. This would allow me to use parameters from a subroutine without having to refactor another parameter being get_defined_vars() as this would obviously uglify my code, which would impeach the reason to refactor in the first place. Test script: --- function a() { $test = 'A'; b(); } function b() { $test = 'B'; $vars_local = get_defined_vars(); $vars_caller = get_caller_vars(); echo $vars_caller['test']; // Expexted: A echo $vars_local['test']; // Expected: B } a(); Expected result: A B Actual result: -- such a function does not exist -- Edit this bug report at http://bugs.php.net/bug.php?id=52593&edit=1
Bug #50921 [Com]: '200 OK' HTTP status despite PHP error
Edit report at http://bugs.php.net/bug.php?id=50921&edit=1 ID: 50921 Comment by: tyra3l at gmail dot com Reported by:phpbug at starurl dot com Summary:'200 OK' HTTP status despite PHP error Status: Bogus Type: Bug Package:HTTP related Operating System: * PHP Version:5.2.12 Block user comment: N New Comment: I can reproduce the problem. I found out, that if I enable xdebug, then I get header 200, if I disable it, then it's 500. Will report it to Derick. Tyrael Previous Comments: [2010-03-12 08:37:24] anzenews at volja dot net I am also having huge problems with this - haproxy health checks do not work reliably because of this bug. Please consider reopening it - it is not bogus. PHP doesn't return HTTP error code, even if display_errors is set to 0. One example: This returns an empty page with status code 200: - HTTP/1.1 200 OK DateFri, 12 Mar 2010 07:27:15 GMT Server Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny6 with Suhosin-Patch X-Powered-ByPHP/5.2.6-1+lenny6 VaryAccept-Encoding Content-Encodinggzip Content-Length 20 Keep-Alive timeout=15, max=100 Connection Keep-Alive Content-Typetext/html - Content-Length is 20, probably because of gzip? There are no spaces around PHP block in source code. I have checked phpinfo() and display_errors is set to Off, so there is no error there. Also, I have tried setting it in php.ini - no change. Another problem: parse errors are also not handled correctly (even if display_errors is set to 0 in php.ini). See previous poster's example. Thanks! [2010-02-03 19:03:56] der...@php.net The reason why display errors needs to be turned of, is because displayed errors generate output, and output causes the headers to be send out. I'm afraid we can't do much about this. [2010-02-03 18:01:37] phpbug at starurl dot com Thank you for the swift response Jani. I can confirm that the 500 status code works for the following (runtime error): But fails for parse errors (because the "disply_errors" line doesn't get executed): Firstly, is this dependency really necessary? Just because we have 'display_errors' enabled doesn't mean we want fatal errors to go unlogged and unnoticed because a "200 OK" status is incorrectly returned. Secondly, the majority of PHP developers out there use shared hosting, on which 'display_errors' is normally true and is impossible to change globally - are we saying they're stuck with incorrect HTTP status codes when parse errors occur? The restriction that headers must not already have been sent is of course understandable as it is unavoidable. Not overriding an explicitly set HTTP status code also makes sense. But why not set the status code as "500 Internal Server Error" when any fatal parse/runtime error occurs, regardless of the value of 'display_errors'? This would be consistent with the HTTP spec, which recommends a 5XX response if an error occurs, and is followed by just about every other web server language out there (e.g., ASP, .NET). Many thanks, BJ [2010-02-03 10:06:27] j...@php.net It does happen. It requires that: 1) display_errors = off 2) No headers have been sent yet by the time the error happens 3) Status is 200 at that time. [2010-02-03 04:23:42] phpbug at starurl dot com Description: My host runs PHP v5.2.12 (confirmed via phpversion) on IIS6 (Windows Server, unknown version). When a PHP error occurs (parse error, runtime error, etc), a "200 OK" HTTP status is returned, instead of the correct "500 Internal Server Error". This is despite claims in the change history for v5.2.4 that this issue was fixed: "Changed error handler to send HTTP 500 instead of blank page on PHP errors. (Dmitry, Andrei Nigmatulin)". This doesn't appear to be the case on IIS6 (monitored remotely via HTTP Spy). Reproduce code: --- Expected result: Parse error mesage and "500 Internal Server Error" HTTP status code. Actual result: -- Parse error mesage and "200 OK" HTTP status code -- Edit this bug report at http://bugs.php.net/bug.php?id=50921&edit=1
Req #52593 [Opn]: Getting scope variables of the caller function
Edit report at http://bugs.php.net/bug.php?id=52593&edit=1 ID: 52593 Updated by: johan...@php.net Reported by:hpolthof at gmail dot com Summary:Getting scope variables of the caller function Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.2.14 Block user comment: N New Comment: Then you also need get_callers_caller_vars() and get_callers_callers_caller_vars() but by definition a function shall be independent from the caller's scope. All required information shall be passed as parameter. Previous Comments: [2010-08-12 15:05:21] dragoo...@php.net Please elaborate on "such a function does not exist" with an exact error message. [2010-08-12 14:45:51] hpolthof at gmail dot com Description: In bug #48290 was the function get_caller_vars() suggested. But in that case it was irrelevant. However do I seek such a function. get_defined_vars() returns the vars in the current scope. As do i like to get the variables of the caller routine. This would allow me to use parameters from a subroutine without having to refactor another parameter being get_defined_vars() as this would obviously uglify my code, which would impeach the reason to refactor in the first place. Test script: --- function a() { $test = 'A'; b(); } function b() { $test = 'B'; $vars_local = get_defined_vars(); $vars_caller = get_caller_vars(); echo $vars_caller['test']; // Expexted: A echo $vars_local['test']; // Expected: B } a(); Expected result: A B Actual result: -- such a function does not exist -- Edit this bug report at http://bugs.php.net/bug.php?id=52593&edit=1
Req #52593 [Com]: Getting scope variables of the caller function
Edit report at http://bugs.php.net/bug.php?id=52593&edit=1 ID: 52593 Comment by: dragoo...@php.net Reported by:hpolthof at gmail dot com Summary:Getting scope variables of the caller function Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.2.14 Block user comment: N New Comment: Please elaborate on "such a function does not exist" with an exact error message. Previous Comments: [2010-08-12 14:45:51] hpolthof at gmail dot com Description: In bug #48290 was the function get_caller_vars() suggested. But in that case it was irrelevant. However do I seek such a function. get_defined_vars() returns the vars in the current scope. As do i like to get the variables of the caller routine. This would allow me to use parameters from a subroutine without having to refactor another parameter being get_defined_vars() as this would obviously uglify my code, which would impeach the reason to refactor in the first place. Test script: --- function a() { $test = 'A'; b(); } function b() { $test = 'B'; $vars_local = get_defined_vars(); $vars_caller = get_caller_vars(); echo $vars_caller['test']; // Expexted: A echo $vars_local['test']; // Expected: B } a(); Expected result: A B Actual result: -- such a function does not exist -- Edit this bug report at http://bugs.php.net/bug.php?id=52593&edit=1
[PHP-BUG] Req #52593 [NEW]: Getting scope variables of the caller function
From: Operating system: PHP version: 5.2.14 Package: *General Issues Bug Type: Feature/Change Request Bug description:Getting scope variables of the caller function Description: In bug #48290 was the function get_caller_vars() suggested. But in that case it was irrelevant. However do I seek such a function. get_defined_vars() returns the vars in the current scope. As do i like to get the variables of the caller routine. This would allow me to use parameters from a subroutine without having to refactor another parameter being get_defined_vars() as this would obviously uglify my code, which would impeach the reason to refactor in the first place. Test script: --- function a() { $test = 'A'; b(); } function b() { $test = 'B'; $vars_local = get_defined_vars(); $vars_caller = get_caller_vars(); echo $vars_caller['test']; // Expexted: A echo $vars_local['test']; // Expected: B } a(); Expected result: A B Actual result: -- such a function does not exist -- Edit bug report at http://bugs.php.net/bug.php?id=52593&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52593&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52593&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52593&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52593&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52593&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52593&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52593&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52593&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52593&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52593&r=support Expected behavior: http://bugs.php.net/fix.php?id=52593&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52593&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52593&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52593&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52593&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52593&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52593&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52593&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52593&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52593&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52593&r=mysqlcfg
Req #30473 [Opn->Bgs]: in_array not working correctly
Edit report at http://bugs.php.net/bug.php?id=30473&edit=1 ID: 30473 Updated by: johan...@php.net Reported by:lenar at city dot ee Summary:in_array not working correctly -Status: Open +Status: Bogus Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: Debian PHP Version:4.3.9 Block user comment: N New Comment: in_array has a third parameter to be strict since PHP 4.2.0. Previous Comments: [2010-08-12 14:27:24] alpust at gmail dot com So, $array_symbols = array(0, '1', '5', 'abc', '<', 'hello'); print in_array('z', $array_symbols); Result: 1 does it normal? [2004-10-19 13:38:18] lenar at city dot ee Trying this as feature request to get review... [2004-10-19 13:36:14] lenar at city dot ee One more comment. What I want to say is that comparisons in array functions should happen like 'eq' operator does it in perl. That would be intuitive. You can't change this, I presume, but that would be the correct way IMHO. [2004-10-19 11:56:05] lenar at city dot ee I don't know then. All I'm sure the logic behind string and int comparison isn't as one would expect from language doing automatic type conversions. You should cast (string) to (int) or (float) only if (string) is numeric. Otherwise it's only logical to cast (int)/(float) operand to string before comparing. That's how I would expect automatic type conversion behave. Currently it's not intuitive. ("test" == 0) evaluating to true just doesn't seem right. Just my $0.02 (which I do not have). [2004-10-19 09:13:42] der...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php There is no BC here, I tried a couple of versions (4.0.0, 4.0.7, 4.1.2, 4.2.3, 4.3.5-4.3.9) and all do this: der...@tequila:/dat/dev/php/php-4.0.0$ ./php X-Powered-By: PHP/4.0.0 Content-type: text/html bool(true) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=30473 -- Edit this bug report at http://bugs.php.net/bug.php?id=30473&edit=1
[PHP-BUG] Bug #52592 [NEW]: mb_ereg_replace and the Greek capital Pi
From: Operating system: Centos 5.5 x64 PHP version: 5.2.14 Package: mbstring related Bug Type: Bug Bug description:mb_ereg_replace and the Greek capital Pi Description: PHP: 5.2.14, Apache 2.2.15, mod_php While \s is supposed to match all whitespace, the greek unicode letter Pi (Î ) whose code is 0xCEA0 is matched too and if replaced with something, it's stripped of its second byte (0xA0). Test script: --- Expected result: Î Î Î ! Î __Î __Î ! %CE%A0++%CE%A0++%CE%A0%21 %CE%A0__%CE%A0__%CE%A0%21 Actual result: -- Î Î Î ! [non printable character]_[non printable character]_[non printable character]! %CE%A0++%CE%A0++%CE%A0%21 %CE_%CE_%CE_%21 -- Edit bug report at http://bugs.php.net/bug.php?id=52592&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52592&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52592&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52592&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52592&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52592&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52592&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52592&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52592&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52592&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52592&r=support Expected behavior: http://bugs.php.net/fix.php?id=52592&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52592&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52592&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52592&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52592&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52592&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52592&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52592&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52592&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52592&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52592&r=mysqlcfg
Req #30473 [Com]: in_array not working correctly
Edit report at http://bugs.php.net/bug.php?id=30473&edit=1 ID: 30473 Comment by: alpust at gmail dot com Reported by:lenar at city dot ee Summary:in_array not working correctly Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Debian PHP Version:4.3.9 Block user comment: N New Comment: So, $array_symbols = array(0, '1', '5', 'abc', '<', 'hello'); print in_array('z', $array_symbols); Result: 1 does it normal? Previous Comments: [2004-10-19 13:38:18] lenar at city dot ee Trying this as feature request to get review... [2004-10-19 13:36:14] lenar at city dot ee One more comment. What I want to say is that comparisons in array functions should happen like 'eq' operator does it in perl. That would be intuitive. You can't change this, I presume, but that would be the correct way IMHO. [2004-10-19 11:56:05] lenar at city dot ee I don't know then. All I'm sure the logic behind string and int comparison isn't as one would expect from language doing automatic type conversions. You should cast (string) to (int) or (float) only if (string) is numeric. Otherwise it's only logical to cast (int)/(float) operand to string before comparing. That's how I would expect automatic type conversion behave. Currently it's not intuitive. ("test" == 0) evaluating to true just doesn't seem right. Just my $0.02 (which I do not have). [2004-10-19 09:13:42] der...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php There is no BC here, I tried a couple of versions (4.0.0, 4.0.7, 4.1.2, 4.2.3, 4.3.5-4.3.9) and all do this: der...@tequila:/dat/dev/php/php-4.0.0$ ./php X-Powered-By: PHP/4.0.0 Content-type: text/html bool(true) [2004-10-18 18:46:24] lenar at city dot ee Description: function in_array() returns wrong result. No way (string) "test" is equal to (int) 0. It is not right to cast needle to the type of array value. The same problem manifests itself with array_search(). You will say propably that you've added third parameter to in_array() to take care of this, but in reality this isn't solution. The problem is you can't blindly cast needle. And manual says: If needle is a string, the comparison is done in a case-sensitive manner. Now tell me how you can compare a string you cast to (int) in case-sensitive manner? And this is all bad because I discovered this by accident after a customer complained their stuff didn't work anymore. That code used to work. I can swear. So you have broken BC it seems. Reproduce code: --- var_dump(in_array("test", array(0)) Expected result: bool(false) Actual result: -- bool(true) -- Edit this bug report at http://bugs.php.net/bug.php?id=30473&edit=1
Bug #52591 [Bgs]: possibility of calling protected static methods in not inherited classes
Edit report at http://bugs.php.net/bug.php?id=52591&edit=1 ID: 52591 User updated by:v dot kholoshenko at gmail dot com Reported by:v dot kholoshenko at gmail dot com Summary:possibility of calling protected static methods in not inherited classes Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: any PHP Version:5.2.14 Block user comment: N New Comment: ok, so why call_user_func doesn't works in such way? Previous Comments: [2010-08-12 13:34:54] johan...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php That is exactly what protected means. [2010-08-12 12:52:32] v dot kholoshenko at gmail dot com Description: PHP allows to call protected static method in classes not inherited from class, that defines this method. See test script. We have two classes inherited from basic abstract class and we can call protected functions (defined abstract) of first class from second. Note, call_user_func caused error (works as expected). Test script: --- http://bugs.php.net/bug.php?id=52591&edit=1
Bug #52591 [Opn->Bgs]: possibility of calling protected static methods in not inherited classes
Edit report at http://bugs.php.net/bug.php?id=52591&edit=1 ID: 52591 Updated by: johan...@php.net Reported by:v dot kholoshenko at gmail dot com Summary:possibility of calling protected static methods in not inherited classes -Status: Open +Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: any PHP Version:5.2.14 Block user comment: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php That is exactly what protected means. Previous Comments: [2010-08-12 12:52:32] v dot kholoshenko at gmail dot com Description: PHP allows to call protected static method in classes not inherited from class, that defines this method. See test script. We have two classes inherited from basic abstract class and we can call protected functions (defined abstract) of first class from second. Note, call_user_func caused error (works as expected). Test script: --- http://bugs.php.net/bug.php?id=52591&edit=1
Bug #35090 [Com]: file i/o is not buffered
Edit report at http://bugs.php.net/bug.php?id=35090&edit=1 ID: 35090 Comment by: surfchen at gmail dot com Reported by:askalski at gmail dot com Summary:file i/o is not buffered Status: Bogus Type: Bug Package:Filesystem function related Operating System: linux PHP Version:5CVS-2005-11-03 (snap) Block user comment: N New Comment: So we need to add a note on the documentation say that this function not supported with filesystem wrapper, right? Previous Comments: [2005-11-03 23:40:24] askalski at gmail dot com > instead it uses the system's file io buffering function > to set the buffer. Assuming you're talking about setvbuf() and not kernel level write-behind caching, this statement is false. The file is opened by _php_stream_fopen(): fd = open(realpath, open_flags, 0666); (It is never subsequently wrapped with fdopen()) At this point, the stream is not buffered at all. When I later call stream_set_write_buffer(), it hits php_stdiop_set_option(): case PHP_STREAM_OPTION_WRITE_BUFFER: if (data->file == NULL) { return -1; } /* setvbuf happens down here */ Because there is no FILE* handle (data->file), setvbuf() is never called for the stream. One of either the documentation (http://us3.php.net/stream_set_write_buffer) or the PHP source is wrong. [2005-11-03 21:34:16] il...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php PHP does not do any buffering itself, instead it uses the system's file io buffering function to set the buffer. There is already a feature request open to enable in-php buffering. [2005-11-03 21:29:08] der...@php.net Can you please answer why this is not a bug Wez? I forgot the reason :) [2005-11-03 19:16:09] askalski at gmail dot com Description: The documentation for stream_set_write_buffer() says that fwrite()s are buffered at 8K by default. In reality, it does not buffer at all. Any attempt to call stream_set_write_buffer() on a regular file handle results in failure. Reproduce code: --- $fh = fopen("asdf", "w"); // write some data using the default buffering for ($i = 0; $i < 5; $i++) fwrite($fh, "test"); // demonstrate that stream_set_write_buffer fails $n = stream_set_write_buffer($fh, 8192); if ($n != 0) echo "stream_set_write_buffer failed\n"; // write some more data to demonstrate the failure for ($i = 0; $i < 5; $i++) fwrite($fh, "again"); fclose($fh); Expected result: PHP should buffer its I/O, and strace should log a single write(). stream_set_write_buffer() should not fail on regular files. Actual result: -- Output: stream_set_write_buffer failed Abridged strace output: open("/tmp/php5-200511031730/asdf", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 lseek(3, 0, SEEK_CUR) = 0 write(3, "test", 4) = 4 write(3, "test", 4) = 4 write(3, "test", 4) = 4 write(3, "test", 4) = 4 write(3, "test", 4) = 4 write(1, "stream_set_write_buffer failed\n", 31) = 31 write(3, "again", 5)= 5 write(3, "again", 5)= 5 write(3, "again", 5)= 5 write(3, "again", 5)= 5 write(3, "again", 5)= 5 close(3)= 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=35090&edit=1
[PHP-BUG] Bug #52591 [NEW]: possibility of calling protected static methods in not inherited classes
From: Operating system: any PHP version: 5.2.14 Package: Scripting Engine problem Bug Type: Bug Bug description:possibility of calling protected static methods in not inherited classes Description: PHP allows to call protected static method in classes not inherited from class, that defines this method. See test script. We have two classes inherited from basic abstract class and we can call protected functions (defined abstract) of first class from second. Note, call_user_func caused error (works as expected). Test script: --- http://bugs.php.net/bug.php?id=52591&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52591&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52591&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52591&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52591&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52591&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52591&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52591&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52591&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52591&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52591&r=support Expected behavior: http://bugs.php.net/fix.php?id=52591&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52591&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52591&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52591&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52591&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52591&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52591&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52591&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52591&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52591&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52591&r=mysqlcfg
Bug #52587 [Opn->Asn]: Clearstatcache() has no effect
Edit report at http://bugs.php.net/bug.php?id=52587&edit=1 ID: 52587 Updated by: paj...@php.net Reported by:a-krcrai at microsoft dot com Summary:Clearstatcache() has no effect -Status: Open +Status: Assigned Type: Bug Package:*Directory/Filesystem functions Operating System: Windows PHP Version:5.3.3 -Assigned To: +Assigned To:pajoye Block user comment: N New Comment: Will double check that with Kris once I'm back. Previous Comments: [2010-08-12 04:54:37] a-krcrai at microsoft dot com Oh, and this was reproduced on both VC6 and VC9 I'm pretty sure. [2010-08-12 04:53:30] a-krcrai at microsoft dot com If you're getting all true dumps, then that means that either you're using 5.2.x (which I'm assuming you're not), or it means that the directory/file exists but that the permissions aren't being successfully applied (or some other weird ACL issue on your system). This is because, even if you couldn't reproduce the bug, you should still be getting false for the first two results, since full access is being denied (meaning the file should be neither readable nor writable). Fortunately, debugging this is pretty simple. I'd like you to do two things for me, if you don't mind: 1. Pipe the exec calls to an array (see php.net/exec for details on how to do this), then do a print_r() of said array and paste the output of that here. This will show us if SetACL is having trouble setting the permissions on your system. 2. *Either*: After the first pair of var_dumps, go ahead and temporarily toss in a die() statement and re-run the script. Then, from the command-line, type "notepad testdir/testfile". If the SetACL calls executed properly, this should pop-up a Notepad window with an "Access Denied" popup message. If, on the other hand, Notepad loads your file just fine, then that means the file is readable and thus the ACL permissions were never applied. *Or*: If you have Powershell installed, open that and CD to whatever directory your PHP script is in. Then type "get-acl testdir/testfile | format-list" and paste the output here. [2010-08-12 04:42:25] ka...@php.net Just did a test following the steps from your comment, my results are so far: php-trunk, VC9, x86, ZTS/NTS: bool(true) bool(true) bool(true) bool(true) php-53, VC9, x86, ZTS/NTS: bool(true) bool(true) bool(true) bool(true) I interpreted your steps as: 1) mkdir testdir 2) php -r "file_put_contents('./testdir/testfile', 'PHP on Windows');" 3) Make a php file with the above code inside 4) php bug52587.php About ACL: C:\php>setacl -help SetACL by Helge Klein Homepage:http://setacl.sourceforge.net Version: 2.0.3.0 Copyright: Helge Klein License: GPL Did you use VC6 or VC9 binaries for your testing? [2010-08-12 03:20:14] a-krcrai at microsoft dot com Description: The results of is_readable() and is_writable() are being cached from the first result on a filesystem object regardless of whether or not clearstatcache() is used or in what form (arguments supplied, etc). This has only been tested on the Windows build of PHP 5.3.3 via the CLI. It's possible that other functions are being improperly cached as well, but I haven't had time to test for all of them as of yet. This does *not*, however, occur in the corresponding Windows builds of PHP 5.3.2. In that version, no caching took place on either of those functions at all. You can easily reproduce this issue if you're running Windows ACL-related tests on the filesystem in PHP 5.3.3. The sample script I put together requires the use of SetACL (better cross-Windows version portability; http://setacl.sourceforge.net) to alter the file permissions. Relative to the test script, create a directory named "testdir", then touch a file within that directory and name it "testfile". We will be using that file for our test. This bug occurs on the ZIP-build of PHP 5.3.3 (both nts and zts) run via CLI without any extensions loaded. It has been successfully reproduced in Windows XP, Windows 2003, Windows 2003 R2, Windows Vista/7, Windows 2008, and Windows 2008 R2. Has not been tested on Linux. Test script: --- http://bugs.php.net/bug.php?id=52587&edit=1
[PHP-BUG] Bug #52590 [NEW]: Hang on
From: Operating system: Windows NT 5.1 b. 2600 SP3 i586 PHP version: 5.3.3 Package: MySQL related Bug Type: Bug Bug description:Hang on Description: When can't connect to server (example: firewall) it hangs on. Do not returns of mysql_connect() or others functions (but returns from mysql_error(), mysql_get_client_info() and others). mysql_get_client_info() returns: mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 $ php_info() returns: System Windows NT PCC 5.1 build 2600 (Windows XP Professional Service Pack 3) i586 Build Date Jul 21 2010 20:00:47 CompilerMSVC6 (Visual C++ 6.0) Architecturex86 Configure Command cscript /nologo configure.js "--enable-snapshot-build" "--disable-isapi" "--enable-debug-pack" "--disable-isapi" "--without-mssql" "--without-pdo-mssql" "--without-pi3web" "--with-pdo-oci=D:\php-sdk\oracle\instantclient10\sdk,shared" "--with-oci8=D:\php-sdk\oracle\instantclient10\sdk,shared" "--with-oci8-11g=D:\php-sdk\oracle\instantclient11\sdk,shared" "--enable-object-out-dir=../obj/" "--enable-com-dotnet" "--with-mcrypt=static" Server API Apache 2.0 Handler Virtual Directory Support enabled Configuration File (php.ini) Path C:\WIN.0 Loaded Configuration File C:\Progs\Internet\Servidor\PHP\php.ini Scan this dir for additional .ini files (none) Additional .ini files parsed(none) PHP API 20090626 PHP Extension 20090626 Zend Extension 220090626 Zend Extension BuildAPI220090626,TS,VC6 PHP Extension Build API20090626,TS,VC6 Debug Build no Thread Safety enabled Zend Memory Manager enabled Zend Multibyte Support disabled IPv6 Supportenabled Registered PHP Streams php, file, glob, data, http, ftp, zip, compress.zlib, compress.bzip2, phar Registered Stream Socket Transports tcp, udp Registered Stream Filters convert.iconv.*, mcrypt.*, mdecrypt.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk, zlib.*, bzip2.* Configuration apache2handler Apache Version Apache/2.2.15 (Win32) PHP/5.3.3 Apache API Version 20051115 Server Administrator[...] Hostname:Port crjt.PCC:0 Max RequestsPer Child: 0 - Keep Alive: on - Max Per Connection: 100 TimeoutsConnection: 300 - Keep-Alive: 5 Virtual Server Yes Server Root C:/Progs/Internet/Servidor/Apache Loaded Modules core mod_win32 mpm_winnt http_core mod_so mod_actions mod_alias mod_asis mod_auth_basic mod_authn_default mod_authn_file mod_authz_default mod_authz_groupfile mod_authz_host mod_authz_user mod_autoindex mod_cgi mod_dir mod_env mod_include mod_isapi mod_log_config mod_mime mod_negotiation mod_setenvif mod_php5 Directive Local Value Master Value engine 1 1 last_modified 0 0 xbithack0 0 Apache Environment VariableValue HTTP_HOST crjt.pcc HTTP_USER_AGENT Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729) HTTP_ACCEPT text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HTTP_ACCEPT_LANGUAGEes-es,es;q=0.8,en-us;q=0.5,en;q=0.3 HTTP_ACCEPT_ENCODINGgzip,deflate HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_KEEP_ALIVE 115 HTTP_CONNECTION keep-alive PATH C:\WIN.0\system32;C:\WIN.0;C:\WIN.0\System32\Wbem;C:\Progs\Ãtil\doxygen\bin SystemRoot C:\WIN.0 COMSPEC C:\WIN.0\system32\cmd.exe PATHEXT .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH WINDIR C:\WIN.0 SERVER_SIGNATUREno value SERVER_SOFTWARE Apache/2.2.15 (Win32) PHP/5.3.3 SERVER_NAME crjt.pcc SERVER_ADDR 127.0.0.1 SERVER_PORT 80 REMOTE_ADDR 127.0.0.1 DOCUMENT_ROOT C:/Usuarios/Reloj.PCC/Mis documentos/My Dropbox/CRJT/nuevo SERVER_ADMIN[...] SCRIPT_FILENAME C:/Usuarios/Reloj.PCC/Mis documentos/My Dropbox/CRJT/nuevo/phpinfo.php REMOTE_PORT 3794 GATEWAY_INTERFACE CGI/1.1 SERVER_PROTOCOL HTTP/1.1 REQUEST_METHOD GET QUERY_STRINGno value REQUEST_URI /phpinfo.php SCRIPT_NAME /phpinfo.php HTTP Headers Information HTTP Request Headers HTTP RequestGET /phpinfo.php HTTP/1.1 Hostcrjt.pcc User-Agent Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729) Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding gzip,deflate Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive 115 Connection keep-alive HTTP Response Headers X-Powered-ByPHP/5.3.3 Keep-Alive timeout=5, max=100 Connection Keep-Alive Transfer-Encoding chunked Content-Typetext/html bcmath BCMath support enabled Directive Local Value Master Value bcma
Bug #52589 [Com]: com_exception when read array from object->property
Edit report at http://bugs.php.net/bug.php?id=52589&edit=1 ID: 52589 Comment by: stinger25 at yandex dot ru Reported by:stinger25 at yandex dot ru Summary:com_exception when read array from object->property Status: Open Type: Bug Package:COM related Operating System: WinXP PHP Version:5.3.3 Block user comment: N New Comment: It's working if instead property write method. VB6 Code Public Function ReadText(index) As String Dim ret As String ReDim str_Text(3) str_Text(0) = "Test zero string" str_Text(1) = "Test first string" str_Text(2) = "Test second string" If ((index < 0) Or (index >= 3)) Then ret = "" Else ret = str_Text(index) End If ReadText = ret End Function and in PHP page Count; print $j.""; for ($i=0; $i<$j; $i++) { // $str = $obj->Text[$i]; $str = $obj->ReadText($i); print $str."" ; } ?> Actual result: 3 Test zero string Test first string Test second string Previous Comments: [2010-08-12 08:52:30] stinger25 at yandex dot ru Description: I have small test ActiveX DLL writen in VB6. It is code of DLL: Option Explicit Private str_Text() As String Public Property Get Text(index As Integer) As String ReDim str_Text(3) str_Text(0) = "Test zero string" str_Text(1) = "Test first string" str_Text(2) = "Test second string" If ((index < 0) Or (index >= 3)) Then Text = "" Else Text = str_Text(index) End If End Property Public Property Get Count() As Long Count = 3 End Property When I trying read array from Text property PHP page generate error, but in VB6 it's working correct. Test script: --- Count; print $j.""; for ($i=0; $i<$j; $i++) { $str = $obj->Text[$i]; print $str."" ; } ?> Expected result: 3 Test zero string Test first string Test second string Actual result: -- 3 Fatal error: Uncaught exception 'com_exception' with message 'Error [0x8002000f] ÐаÑамеÑÑ ÑвлÑеÑÑÑ Ð¾Ð±ÑзаÑелÑнÑм. ' in C:\Inetpub\_web_script_\SKU_Buffer\docsgenerator\xls.php:8 Stack trace: #0 C:\Inetpub\_web_script_\SKU_Buffer\docsgenerator\xls.php(8): unknown() #1 {main} thrown in C:\Inetpub\_web_script_\SKU_Buffer\docsgenerator\xls.php on line 8 -- Edit this bug report at http://bugs.php.net/bug.php?id=52589&edit=1