Bug #64720 [Asn-Csd]: SegFault on zend_deactivate
Edit report at https://bugs.php.net/bug.php?id=64720edit=1 ID: 64720 Updated by: dmi...@php.net Reported by:d dot ananyev at gmail dot com Summary:SegFault on zend_deactivate -Status: Assigned +Status: Closed Type: Bug Package:Reproducible crash Operating System: CentOS release 6.4 (Final) PHP Version:5.4.10 Assigned To:dmitry Block user comment: N Private report: N New Comment: Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=77f15762137e2d8173df9b733b4cb70fc996 Log: Fixed bug #64720 (SegFault on zend_deactivate) Previous Comments: [2013-05-21 05:09:53] dmi...@php.net Script to Reproduce --- ?php class Stat { private static $requests; public static function getInstance() { if (!isset(self::$requests[1])) { self::$requests[1] = new self(); } return self::$requests[1]; } public function __destruct() { unset(self::$requests[1]); } } class Foo { public function __construct() { Stat::getInstance(); } } class Error { private $trace; public function __construct() { $this-trace = debug_backtrace(1); } } class Bar { public function __destruct() { Stat::getInstance(); new Error(); } public function test() { new Error(); } } $foo = new Foo(); $bar = new Bar(); $bar-test(); ? The crash occurs because PHP tries to access static properties of class Stat after they are destroyed. ==22607== Invalid read of size 4 ==22607==at 0x84EA438: _zval_dtor_func (zend_variables.c:46) ==22607==by 0x84DAA42: _zval_dtor (zend_variables.h:35) ==22607==by 0x84DAAEF: i_zval_ptr_dtor (zend_execute.h:81) ==22607==by 0x84DB851: _zval_ptr_dtor (zend_execute_API.c:428) ==22607==by 0x84E032A: cleanup_user_class_data (zend_opcode.c:169) ==22607==by 0x84E0419: zend_cleanup_user_class_data (zend_opcode.c:202) ==22607==by 0x84FC771: zend_hash_reverse_apply (zend_hash.c:799) ==22607==by 0x84DB4BE: shutdown_executor (zend_execute_API.c:289) ==22607==by 0x84EC528: zend_deactivate (zend.c:939) ==22607==by 0x84744D6: php_request_shutdown (main.c:1800) ==22607==by 0x8585386: do_cli (php_cli.c:1176) ==22607==by 0x8585B2F: main (php_cli.c:1377) ==22607== Address 0x4949fa8 is 0 bytes inside a block of size 20 free'd ==22607==at 0x4007F0F: free (vg_replace_malloc.c:446) ==22607==by 0x84BFEA5: _efree (zend_alloc.c:2437) ==22607==by 0x851CDEB: i_zval_ptr_dtor (zend_execute.h:82) ==22607==by 0x8541EA6: ZEND_UNSET_DIM_SPEC_VAR_CONST_HANDLER (zend_vm_execute.h:15900) ==22607==by 0x8521499: execute_ex (zend_vm_execute.h:356) ==22607==by 0x85214FD: zend_execute (zend_vm_execute.h:381) ==22607==by 0x84DD3D5: zend_call_function (zend_execute_API.c:941) ==22607==by 0x85080A9: zend_call_method (zend_interfaces.c:97) ==22607==by 0x8515232: zend_objects_destroy_object (zend_objects.c:123) ==22607==by 0x851B546: zend_objects_store_del_ref_by_handle_ex (zend_objects_API.c:207) ==22607==by 0x851B426: zend_objects_store_del_ref (zend_objects_API.c:173) ==22607==by 0x84EA474: _zval_dtor_func (zend_variables.c:54) [2013-04-29 09:14:46] d dot ananyev at gmail dot com It's not opcache related [2013-04-29 09:01:31] d dot ananyev at gmail dot com We've got the same segfault trace without any opcode cache. Core was generated by `php-fpm: pool www '. Program terminated with signal 11, Segmentation fault. #0 _zend_mm_free_int (heap=0x1177330, p=0x17926c0) at /usr/build/php- 5.4.10/php-5.4.10/Zend/zend_alloc.c:2100 2100if (ZEND_MM_IS_FREE_BLOCK(next_block)) { Missing separate debuginfos, use: debuginfo-install fftw-3.2.1-3.1.el6.x86_64 lcms-libs-1.19-1.el6.x86_64 libc-client-2007e-11.el6.x86_64 libidn-1.18- 2.el6.x86_64 libmcrypt-2.5.8-9.el6.x86_64 librabbitmq-0.2- 0.1.git2059570.el6.remi.x86_64 libtool-ltdl-2.2.6-15.5.el6.x86_64 xz-libs- 4.999.9-0.3.beta.20091007git.el6.x86_64 (gdb) bt #0 _zend_mm_free_int (heap=0x1177330, p=0x17926c0) at /usr/build/php- 5.4.10/php-5.4.10/Zend/zend_alloc.c:2100 #1 0x007116d7 in _zval_dtor (zval_ptr=0x16beb60) at /usr/build/php- 5.4.10/php-5.4.10/Zend/zend_variables.h:35 #2 _zval_ptr_dtor (zval_ptr=0x16beb60) at /usr/build/php-5.4.10/php- 5.4.10/Zend/zend_execute_API.c:438 #3 0x007163af in cleanup_user_class_data (pce=value optimized out) at /usr/build/php-5.4.10/php-5.4.10/Zend/zend_opcode.c:165 #4 zend_cleanup_user_class_data (pce=value optimized out) at /usr/build/php-
Bug #64720 [Csd-Asn]: SegFault on zend_deactivate
Edit report at https://bugs.php.net/bug.php?id=64720edit=1 ID: 64720 Updated by: dmi...@php.net Reported by:d dot ananyev at gmail dot com Summary:SegFault on zend_deactivate -Status: Closed +Status: Assigned Type: Bug Package:Reproducible crash Operating System: CentOS release 6.4 (Final) PHP Version:5.4.10 Assigned To:dmitry Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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: [2013-05-21 06:34:09] dmi...@php.net Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=77f15762137e2d8173df9b733b4cb70fc996 Log: Fixed bug #64720 (SegFault on zend_deactivate) [2013-05-21 05:09:53] dmi...@php.net Script to Reproduce --- ?php class Stat { private static $requests; public static function getInstance() { if (!isset(self::$requests[1])) { self::$requests[1] = new self(); } return self::$requests[1]; } public function __destruct() { unset(self::$requests[1]); } } class Foo { public function __construct() { Stat::getInstance(); } } class Error { private $trace; public function __construct() { $this-trace = debug_backtrace(1); } } class Bar { public function __destruct() { Stat::getInstance(); new Error(); } public function test() { new Error(); } } $foo = new Foo(); $bar = new Bar(); $bar-test(); ? The crash occurs because PHP tries to access static properties of class Stat after they are destroyed. ==22607== Invalid read of size 4 ==22607==at 0x84EA438: _zval_dtor_func (zend_variables.c:46) ==22607==by 0x84DAA42: _zval_dtor (zend_variables.h:35) ==22607==by 0x84DAAEF: i_zval_ptr_dtor (zend_execute.h:81) ==22607==by 0x84DB851: _zval_ptr_dtor (zend_execute_API.c:428) ==22607==by 0x84E032A: cleanup_user_class_data (zend_opcode.c:169) ==22607==by 0x84E0419: zend_cleanup_user_class_data (zend_opcode.c:202) ==22607==by 0x84FC771: zend_hash_reverse_apply (zend_hash.c:799) ==22607==by 0x84DB4BE: shutdown_executor (zend_execute_API.c:289) ==22607==by 0x84EC528: zend_deactivate (zend.c:939) ==22607==by 0x84744D6: php_request_shutdown (main.c:1800) ==22607==by 0x8585386: do_cli (php_cli.c:1176) ==22607==by 0x8585B2F: main (php_cli.c:1377) ==22607== Address 0x4949fa8 is 0 bytes inside a block of size 20 free'd ==22607==at 0x4007F0F: free (vg_replace_malloc.c:446) ==22607==by 0x84BFEA5: _efree (zend_alloc.c:2437) ==22607==by 0x851CDEB: i_zval_ptr_dtor (zend_execute.h:82) ==22607==by 0x8541EA6: ZEND_UNSET_DIM_SPEC_VAR_CONST_HANDLER (zend_vm_execute.h:15900) ==22607==by 0x8521499: execute_ex (zend_vm_execute.h:356) ==22607==by 0x85214FD: zend_execute (zend_vm_execute.h:381) ==22607==by 0x84DD3D5: zend_call_function (zend_execute_API.c:941) ==22607==by 0x85080A9: zend_call_method (zend_interfaces.c:97) ==22607==by 0x8515232: zend_objects_destroy_object (zend_objects.c:123) ==22607==by 0x851B546: zend_objects_store_del_ref_by_handle_ex (zend_objects_API.c:207) ==22607==by 0x851B426: zend_objects_store_del_ref (zend_objects_API.c:173) ==22607==by 0x84EA474: _zval_dtor_func (zend_variables.c:54) [2013-04-29 09:14:46] d dot ananyev at gmail dot com It's not opcache related [2013-04-29 09:01:31] d dot ananyev at gmail dot com We've got the same segfault trace without any opcode cache. Core was generated by `php-fpm: pool www '. Program terminated with signal 11, Segmentation fault. #0 _zend_mm_free_int (heap=0x1177330, p=0x17926c0) at /usr/build/php- 5.4.10/php-5.4.10/Zend/zend_alloc.c:2100 2100if (ZEND_MM_IS_FREE_BLOCK(next_block)) { Missing separate debuginfos, use: debuginfo-install fftw-3.2.1-3.1.el6.x86_64 lcms-libs-1.19-1.el6.x86_64 libc-client-2007e-11.el6.x86_64 libidn-1.18- 2.el6.x86_64 libmcrypt-2.5.8-9.el6.x86_64 librabbitmq-0.2- 0.1.git2059570.el6.remi.x86_64 libtool-ltdl-2.2.6-15.5.el6.x86_64 xz-libs- 4.999.9-0.3.beta.20091007git.el6.x86_64 (gdb) bt #0 _zend_mm_free_int (heap=0x1177330, p=0x17926c0) at /usr/build/php- 5.4.10/php-5.4.10/Zend/zend_alloc.c:2100 #1 0x007116d7 in
Bug #29992 [Com]: foreach by reference corrupts the array
Edit report at https://bugs.php.net/bug.php?id=29992edit=1 ID: 29992 Comment by: email at stevemann dot net Reported by:fletch at pobox dot com Summary:foreach by reference corrupts the array Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: linux PHP Version:5.0.1 Block user comment: N Private report: N New Comment: Agreed this is not a bug, it's expected behaviour. But it's dangerous as it can slip by without being noticed. It almost certainly means there are thousands of sites which are exhibiting wrong behaviour because of this and no-one realises. Surely the concept of scoping the 'as' variable to the foreach enclosure only can't be considered bad form. It would make so much more sense to 'opt-in' to retrieving the variable outside of the enclosure (by assigning to another persistent variable within the enclosure) rather than the current 'opt-out' system (using unset()) which, unless you happen to have read the warning is HIGHLY DANGEROUS. Previous Comments: [2013-05-20 15:57:18] paul dot dillinger at gmail dot com OK, I went over this some more. pre ?php // Fresh array $clean = array(1,2,3,4); foreach($clean as $item){ // Nothing is modified in the array, but $item now exists } /*## * $item persists outside of foreach and is now $clean[3] * See the warning on http://php.net/manual/en/control-structures.foreach.php * print_r($item); // would return 4 you you uncommented this. * unset($item); // This would remove the pointer to $clean[3]. Expected. **/ echo A:\n; /*A*/ print_r($clean); // $clean is still unmodified echo B:\n; foreach($clean as $item){ /*## * Using AS $item SETS $item TO the current $item value (a.k.a. $clean[0], etc.) * Essentially foreach($clean as $item) is short hand for something like: * $x=0;while($x count($clean)){$item=$clean[$x]; ### your code ### $x++;} * The problem I had was that I did not expect foreach to be able to set on call **/ /*B*/ print_r($clean); } ? /pre So creating the variable is documented, and it isn't a bug. The ability to set the value could be made clearer though. [2013-05-20 09:51:33] richard at ejem dot cz This IS a bug and SHOULD be finally fixed. It is weird, hard to debug and unexpected behavior which took me many hours of life finding the problem. Almost every modern programming language has a variable context, which guarrantees the foreach variable is not visible after exiting the loop. Anyone is using it intentionally for weird reason? come on guys, almost every bug can be used for some hacking or weird reasons, will it stop you from fixing other bugs? no! Sorry for mee-to like post, but I do it for the good of next PHP programmer generations who will also lose hours of their lives discovering this nonsense. Please fix it. [2012-10-25 17:01:03] paul dot dillinger at gmail dot com I understand that my explanation above isn't 100% accurate (unset really doesn't have anything to do with it), but that doesn't change that the expected behavior is not working. Rasmus said: Ok, simple question then. Do you expect this to output 3? foreach(array(1,2,3) as $b) { } echo $b; If you do, then you don't want us to fix this bug because fixing it would mean $b is not 3 here. I say in the example above, would you expect a print_r of the same array to return 1,2,2? My issue was that the content of the entire array. Honestly I've been programming since I was eight years old. That was 1985. If this was confusing the hell out of me then something's wrong. Here's an even simpler example: pre ?php $clean = array(1,2,3,4); foreach($clean as $item){ // Nothing } echo A:\n; /*A*/ print_r($clean); echo B:\n; foreach($clean as $item){ /*B*/ print_r($clean); } $clean = array(1,2,3,4); foreach($clean as $item){ // Nothing } echo C:\n; /*C*/ print_r($clean); echo D:\n; foreach($clean as $not_item){ /*C*/ print_r($clean); } ? /pre A and B output the same array differently with no modification (not expected). C and D are the same (expected). The only change was not re-using the name $item. How can we make it so that using $item in one foreach and then using the same variable name ($item) in a
Bug #64886 [Opn-Nab]: Different return value between within or without an object
Edit report at https://bugs.php.net/bug.php?id=64886edit=1 ID: 64886 Updated by: ni...@php.net Reported by:fm dot lheureux at gmail dot com Summary:Different return value between within or without an object -Status: Open +Status: Not a bug Type: Bug Package:Unknown/Other Function Operating System: Ubuntu 13.04x64 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2013-05-21 02:53:30] fm dot lheureux at gmail dot com This bug can be killed. When writing it I realized my mistake. When the get_class method is invoked with the null parameter, it returns the class of where it's being called, hence Toto. Not a bug! [2013-05-21 02:38:07] fm dot lheureux at gmail dot com Description: I would expect a getter to return the same value whether it's being called within or without an object. In my example, my __get function always returns null. If it's being called from outside the object, it behaves properly and returns null. If it's being called from inside, it returns the object itself. Here I used the __get function to make it even clearer, but it does the same regardless of the presence of that function. Test script: --- ?php class Toto{ function __get($p){ return null; } function doit(){ echo get_class($this-wololo); //this will print TOTO, but why? } } $t = new Toto(); $t-doit(); echo \n; echo get_class($t-wololo); //this will not work, which is what I expect echo \n; Expected result: PHP Warning: get_class() called without object from outside a class in /home/fmlheureux/test.php on line 9 PHP Warning: get_class() called without object from outside a class in /home/fmlheureux/test.php on line 16 Actual result: -- Toto PHP Warning: get_class() called without object from outside a class in /home/fmlheureux/test.php on line 16 -- Edit this bug report at https://bugs.php.net/bug.php?id=64886edit=1
[PHP-BUG] Req #64887 [NEW]: Add microseconds to DateTime::format
From: glass at glasshalfawesome dot com Operating system: Win7 PHP version: Irrelevant Package: Date/time related Bug Type: Feature/Change Request Bug description:Add microseconds to DateTime::format Description: From what I can find it's currently not possible to add or subtract microseconds using DateTime::format. Every other unit of time can be added or subtracted. Please consider adding: decisecond centisecond millisecond microsecond Test script: --- $time = new DateTime('01:01:01.01'); $timeH = $time-modify('+1 hour'); echo $timeH-format('H:i:s.u') . 'br'; // prints 02:01:01.01 $timeM = $time-modify('+1 minute'); echo $timeM-format('H:i:s.u') . 'br'; // prints 02:02:01.01 $timeS = $time-modify('+1 second'); echo $timeS-format('H:i:s.u') . 'br'; // prints 02:02:02.01 $timeMS = $time-modify('+1 microsecond'); echo $timeMS-format('H:i:S:u') . 'br'; // error -- Edit bug report at https://bugs.php.net/bug.php?id=64887edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64887r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64887r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64887r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64887r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64887r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64887r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64887r=needscript Try newer version: https://bugs.php.net/fix.php?id=64887r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64887r=support Expected behavior: https://bugs.php.net/fix.php?id=64887r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64887r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64887r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64887r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64887r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64887r=dst IIS Stability: https://bugs.php.net/fix.php?id=64887r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64887r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64887r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64887r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64887r=mysqlcfg
Bug #52913 [Com]: Incorrect SNI (Server name indicator) when using a SoapClient through a proxy
Edit report at https://bugs.php.net/bug.php?id=52913edit=1 ID: 52913 Comment by: taneli at crasman dot fi Reported by:terje dot gjerde at visma dot no Summary:Incorrect SNI (Server name indicator) when using a SoapClient through a proxy Status: Open Type: Bug Package:OpenSSL related Operating System: Windows Server 2008 r2 PHP Version:5.3.3 Block user comment: N Private report: N New Comment: You can workaround this option by specifying a SNI_server_name in a stream context like this: $wsdl = 'http://what.ever.host/service.wsdl'; $host = parse_url($wsdl, PHP_URL_HOST); $opts = array('ssl' = array('SNI_server_name' = $host, 'SNI_enabled' = TRUE)); $context = stream_context_create($opts); $soap = new \SoapClient($wsdl, array('proxy_host' = 'localhost', 'proxy_port' = 8080, 'stream_context' = $context)); Previous Comments: [2012-07-02 08:17:41] daniel dot buschke at nextiraone dot eu We have reproduced this bug in PHP 5.3.10 on Linux (OpenWRT). If you set an IP as proxy, PHP is shouting an internal IP address out to the world. I think that is critical, isn't it? regards Daniel [2012-06-26 16:58:31] daniel dot buschke at nextiraone dot eu Workaround: Locallly override APACHESERVER with the IP of PROXY in hosts file and set APACHESERVER as $config['proxy_host']. This is very ugly but works (for us). cheers Daniel [2010-09-23 16:23:51] terje dot gjerde at visma dot no Description: When calling a url on apache server with name APACHESERVER through a proxy with name PROXY the following error occurs: Hostname PROXY provided via SNI and hostname APACHESERVER provided via HTTP are different ie calling url: https://APACHESERVER/ws.php with proxy at: http://PROXY:8080/ Test script: --- $config = array('location' = WEBSERVICE_LOCATION, 'classmap' = $wsclassmap, 'trace' = 1, ); if (WEBSERVICE_PROXY_HOST WEBSERVICE_PROXY_PORT) { $config['proxy_host'] = WEBSERVICE_PROXY_HOST; $config['proxy_port'] = WEBSERVICE_PROXY_PORT; } $ws_client = new SoapClient($wsdl,$config); -- Edit this bug report at https://bugs.php.net/bug.php?id=52913edit=1
Bug #64836 [Asn-Fbk]: segfault in softmagic.c
Edit report at https://bugs.php.net/bug.php?id=64836edit=1 ID: 64836 Updated by: a...@php.net Reported by:r dot biegel at gmx dot at Summary:segfault in softmagic.c -Status: Assigned +Status: Feedback Type: Bug Package:Unknown/Other Function Operating System: Gentoo Linux PHP Version:5.4.15 Assigned To:ab Block user comment: N Private report: N New Comment: I've just compiled apache 2.4 with subversion 1.7.x module plus PHP-5.5, TS build. But it still doesn't crash for me. Note that the libmagic is the same in 5.4 and 5.5 and was upgraded in 5.4.15 and 5.5.0 beta4. To diagnose it further, is it possible you to check if the behavior is the same with the earlier php versions? May be 5.4.14 or 5.5.0 beta3. Also i think this behaviour is TS specific, svn might be even not the cause, too. btw what do you mean not using -D SVN? As i've experienced the mod_dav_svn.so has to be built from the subversion sources and is not contained in the apache source tree. Thanks. Previous Comments: [2013-05-19 15:31:46] r dot biegel at gmx dot at I used this little script to test the finfo_file function on its own. Crashes in apache (if the file $fn exists, filetype doesn't matter), but it works on cli: ?php $finfo = finfo_open(); $fn = index.html; echo File .$fn. is of type .finfo_file($finfo,$fn); finfo_close($finfo); ? So it has something to do with apache i thought and it turned out that disabling SVN DAV in apache (not using -D SVN) fixes the problem. How can I investigate further? Btw, I already upgraded from apache 2.2 to 2.4 before my first report. Here another (more detailed) bt: Thread 28 (Thread 0x7fffd9feb700 (LWP 24821)): #0 0x7fffeeec2e6b in mget (ms=0x7fffd411c5f0, s=0x7fffd8896030 GIF89a, m=0x7fffd8a69268, nbytes=1218, o=0, cont_level=0, mode=32, text=0, flip=0, recursion_level=1, printed_something=0x7fffd9fe7dd4, need_separator=0x7fffd9fe7dd8, returnval=0x7fffd9fe7d24) at ext/fileinfo/libmagic/softmagic.c:1610 off = 0 soffset = 410814606 offset = 0 count = 0 rv = -207172457 oneed_separator = 994741513 sbuf = 0x5cb76acd3615aac9 Address 0x5cb76acd3615aac9 out of bounds rbuf = 0x8efc10f4e7cb6d6d Address 0x8efc10f4e7cb6d6d out of bounds p = 0x7fffd411c660 ml = {magic = 0x180ffedff931d7c7, nmagic = 1473718312, map = 0xd8c865c8, next = 0x7fffd411c5f0, prev = 0x1a09a2a9d9c97089} #1 0x7fffeeebede8 in match (ms=0x7fffd411c5f0, magic=0x7fffd89170e8, nmagic=9629, s=0x7fffd8896030 GIF89a, nbytes=1218, offset=0, mode=32, text=0, flip=0, recursion_level=0, printed_something=0x7fffd9fe7dd4, need_separator=0x7fffd9fe7dd8, returnval=0x7fffd9fe7d24) at ext/fileinfo/libmagic/softmagic.c:157 flush = 0 m = 0x7fffd8a69268 magindex = 5584 cont_level = 0 returnvalv = 0 e = -647236122 firstline = 1 print = 0 #2 0x7fffeeebeb19 in file_softmagic (ms=0x7fffd411c5f0, buf=0x7fffd8896030 GIF89a, nbytes=1218, mode=32, text=0) at ext/fileinfo/libmagic/softmagic.c:82 ml = 0x7fffd40efb50 rv = 32767 printed_something = 0 need_separator = 0 #3 0x7fffeeebc3a5 in file_buffer (ms=0x7fffd411c5f0, stream=0x7fffd8d70388, inname=0x0, buf=0x7fffd8896030, nb=1218) at ext/fileinfo/libmagic/funcs.c:238 m = 0 rv = 0 looks_text = 0 mime = 16 ubuf = 0x7fffd8896030 GIF89a u8buf = 0x7fffd4255aa0 ulen = 3 code = 0x0 code_mime = 0x7fffef6f618f binary type = 0x7fffef6f5f84 binary #4 0x7fffeeebd698 in file_or_stream (ms=0x7fffd411c5f0, inname=0x0, stream=0x7fffd8d70388) at ext/fileinfo/libmagic/magic.c:413 rv = -1 buf = 0x7fffd8896030 GIF89a sb = {st_dev = 2058, st_ino = 105911862, st_nlink = 1, st_mode = 33188, st_uid = 81, st_gid = 81, __pad0 = 0, st_rdev = 0, st_size = 1218, st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1322087240, tv_nsec = 505034622}, st_mtim = {tv_sec = 1276182426, tv_nsec = 0}, st_ctim = { tv_sec = 1368462842, tv_nsec = 483233520}, __unused = {0, 0, 0}} nbytes = 1218 no_in_stream = 0 tsrm_ls = 0x7fffd40068f0 #5 0x7fffeeebd441 in magic_stream (ms=0x7fffd411c5f0, stream=0x7fffd8d70388) at ext/fileinfo/libmagic/magic.c:345 No locals. #6 0x7fffeeeae9b8 in _php_finfo_get_type (ht=2, return_value=0x7fffd49f1e50, return_value_ptr=0x0, this_ptr=0x7fffd49f3d58, return_value_used=1, tsrm_ls=0x7fffd40068f0, mode=2, mimetype_emu=0) at ext/fileinfo/fileinfo.c:540 stream = 0x7fffd8d70388 context = 0x7fffd8b84610 tmp2 = 0x7fffd49db410 /xxx/yyy/zzz/fileadmin/template/head.gif wrap =
Req #63834 [Com]: Add a function to detect a methods calling context
Edit report at https://bugs.php.net/bug.php?id=63834edit=1 ID: 63834 Comment by: tolan333 at gmail dot com Reported by:tolan333 at gmail dot com Summary:Add a function to detect a methods calling context Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Thanks for the comments. After rethinking about this, krakjoe's suggestions seems to be superior (solves the issue and is way easier). Is their any chance to see this improvement in 5.5 or 5.6? Or what needs to be done to get this implemented? Previous Comments: [2012-12-31 12:02:45] krak...@php.net acquiring a backtrace is an inefficient means of obtaining this information ... [2012-12-31 11:55:17] ni...@php.net I still fail to use just what exactly this asks for and how it would be beneficial. @krakjoe: The get_calling_method and get_calling_class functions you added should already be fully covered by debug_backtrace, so I see little value in adding them (as the use case is rather limited). @op: Regarding the last two PHP_CONTEXT_EXTERN constants, what do you mean by user and core? E.g. if you invoke a callback using call_user_func, is that an internal or a userland call? It's the internal function doing the call, but it's really the user who triggers it. I don't see how these constants would carry any meaning. The other two again can be covered by debug_backtrace, can't they? Just get the class of the call and check whether it equals __CLASS__ (= private) or is a subclass of __CLASS__ (= protected) or is none (= public). Seems simple enough to me. [2012-12-31 11:49:59] krak...@php.net The following patch has been added/updated: Patch Name: 63834-2.patch Revision: 1356954599 URL: https://bugs.php.net/patch-display.php?bug=63834patch=63834-2.patchrevision=1356954599 [2012-12-31 11:37:55] krak...@php.net -2 will provide get_calling_method and get_calling_class, I think that's everything you should need [2012-12-31 11:36:48] krak...@php.net The following patch has been added/updated: Patch Name: 63834-2.patch Revision: 1356953808 URL: https://bugs.php.net/patch-display.php?bug=63834patch=63834-2.patchrevision=1356953808 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=63834 -- Edit this bug report at https://bugs.php.net/bug.php?id=63834edit=1
Bug #64868 [Fbk-Opn]: segfault in zval_mark_grey(), Zend/zend_gc.c:421
Edit report at https://bugs.php.net/bug.php?id=64868edit=1 ID: 64868 User updated by:martin dot schuette at icans-gmbh dot com Reported by:martin dot schuette at icans-gmbh dot com Summary:segfault in zval_mark_grey(), Zend/zend_gc.c:421 -Status: Feedback +Status: Open Type: Bug Package:Reproducible crash Operating System: Debian Linux PHP Version:5.4.15 Block user comment: N Private report: N New Comment: So far I was unable to reproduce the crash with a smaller code sample (i.e. without requiring our complete application and test suite). Previous Comments: [2013-05-17 10:57:43] larue...@php.net could you please provide a reproduce test script? thanks [2013-05-17 10:47:30] martin dot schuette at icans-gmbh dot com Description: As part of a PHPUnit test suite I get this segfault. Interestingly it depends on phpunit's command line options. Segfault with phpunit -c app/phpunit.xml.dist --log-junit /dev/null No problem with phpunit -c app/phpunit.xml.dist and phpunit -c app/phpunit.xml.dist --log-junit /dev/null --debug Without GC it works as well: php -dzend.enable_gc=0 /usr/bin/phpunit -c app/phpunit.xml.dist --log-junit /dev/null Expected result: complete PHPUnit run Actual result: -- deploy@jenkins:/tmp/gitphp -v PHP 5.4.4-14 (cli) (built: Mar 4 2013 14:08:43) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies deploy@jenkins:/tmp/gitgdb --args php /usr/bin/phpunit -c app/phpunit.xml.dist --log-junit /dev/null GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/php...Reading symbols from /usr/lib/debug/usr/bin/php5...done. done. (gdb) run Starting program: /usr/bin/php /usr/bin/phpunit -c app/phpunit.xml.dist --log-junit /dev/null [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. warning: the debug information found in /usr/lib/debug//usr/lib/php5/20100525/mysql.so does not match /usr/lib/php5/20100525/mysql.so (CRC mismatch). warning: the debug information found in /usr/lib/debug/usr/lib/php5/20100525/mysql.so does not match /usr/lib/php5/20100525/mysql.so (CRC mismatch). warning: the debug information found in /usr/lib/debug//usr/lib/php5/20100525/mysqli.so does not match /usr/lib/php5/20100525/mysqli.so (CRC mismatch). warning: the debug information found in /usr/lib/debug/usr/lib/php5/20100525/mysqli.so does not match /usr/lib/php5/20100525/mysqli.so (CRC mismatch). warning: the debug information found in /usr/lib/debug//usr/lib/php5/20100525/pdo_mysql.so does not match /usr/lib/php5/20100525/pdo_mysql.so (CRC mismatch). warning: the debug information found in /usr/lib/debug/usr/lib/php5/20100525/pdo_mysql.so does not match /usr/lib/php5/20100525/pdo_mysql.so (CRC mismatch). [New Thread 0x7fffe80d8700 (LWP 27679)] [Thread 0x7fffe80d8700 (LWP 27679) exited] PHPUnit 3.7.10 by Sebastian Bergmann. Configuration read from /tmp/git/app/phpunit.xml.dist . 61 / 3421 ( 1%) ...S. 122 / 3421 ( 3%) . 183 / 3421 ( 5%) . 244 / 3421 ( 7%) . 305 / 3421 ( 8%) . 366 / 3421 ( 10%) . 427 / 3421 ( 12%) . 488 / 3421 ( 14%) . 549 / 3421 ( 16%) . 610 / 3421 ( 17%) . 671 / 3421 ( 19%) . 732 / 3421 ( 21%) . 793 / 3421 ( 23%) . 854 / 3421 ( 24%) . 915 / 3421 ( 26%) . 976 / 3421 ( 28%)
[PHP-BUG] Bug #64888 [NEW]: Integer Overflow when processing MAX_FILE_SIZE
From: php at paalsteek dot de Operating system: Arch Linux PHP version: 5.4.15 Package: FPM related Bug Type: Bug Bug description:Integer Overflow when processing MAX_FILE_SIZE Description: When uploading files I get an error UPLOAD_ERR_FORM_SIZE when setting MAX_FILE_SIZE in the input form to values greater or equal to 2147483648 (2^31). This problem does not exist on a CentOS 6.4 using Apache 2.2.15. Therefore I guess this is an implementation specific problem of php-fpm. Test script: --- HTML form: html body form action=https://owncloud.paalsteek.de/test.php; method=post enctype=multipart/form-data input id=max_upload type=hidden value=2147483648 name=MAX_FILE_SIZE original-title= input id=requesttoken type=hidden value=013ac1f5ecd5e025b1ee name=requesttoken original-title= input class=max_human_file_size type=hidden value=(max 2.3 GB) original-title= input id=dir type=hidden value=/ name=dir original-title= input type=file name=test / input type=submit / /form /body /html PHP code: ?php var_dump($_FILES[test][error]); ? Expected result: int(0) Actual result: -- int(2) -- Edit bug report at https://bugs.php.net/bug.php?id=64888edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64888r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64888r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64888r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64888r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64888r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64888r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64888r=needscript Try newer version: https://bugs.php.net/fix.php?id=64888r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64888r=support Expected behavior: https://bugs.php.net/fix.php?id=64888r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64888r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64888r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64888r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64888r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64888r=dst IIS Stability: https://bugs.php.net/fix.php?id=64888r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64888r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64888r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64888r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64888r=mysqlcfg
Bug #62523 [Com]: php crashes with segfault when exif_read_data called
Edit report at https://bugs.php.net/bug.php?id=62523edit=1 ID: 62523 Comment by: dominic dot benson at thirdlight dot com Reported by:bigbug at mafia dot lv Summary:php crashes with segfault when exif_read_data called Status: Assigned Type: Bug Package:Reproducible crash Operating System: linux PHP Version:5.3Git-2012-07-10 (snap) Assigned To:rasmus Block user comment: N Private report: N New Comment: I encountered a similar issue reading EXIF from a TIFF, the below patch fixes both my original TIFF issue, and the issue with file 1.orig.jpg linked in the original report for me. Environment: Linux amd64/i686 (Debian 5/6/7, Ubuntu 13.04) PHP version: 5.3.25 SAPI: CLI/FastCGI Required for the JPEG fix is a change from int type for offset_diff in exif_process_IFD_in_MAKERNOTE. I've changed it to size_t, which is semantically correct for Linux, but I think this isn't portable to Win. Essentially, the issue is that values read from the file are treated as offsets, and used to manipulate the offset_base. Patch (agains 5.3.25) follows: diff -rupN php-5.3.25.orig/ext/exif/exif.c php-5.3.25/ext/exif/exif.c --- php-5.3.25.orig/ext/exif/exif.c 2013-05-08 16:58:52.0 +0100 +++ php-5.3.25/ext/exif/exif.c 2013-05-21 14:59:59.579438565 +0100 @@ -2745,7 +2745,8 @@ static int exif_process_unicode(image_in static int exif_process_IFD_in_MAKERNOTE(image_info_type *ImageInfo, char * value_ptr, int value_len, char *offset_base, size_t IFDlength, size_t displacement TSRMLS_DC) { int de, i=0, section_index = SECTION_MAKERNOTE; - int NumDirEntries, old_motorola_intel, offset_diff; + int NumDirEntries, old_motorola_intel; + size_t offset_diff; const maker_note_type *maker_note; char *dir_start; @@ -2921,6 +2922,12 @@ static int exif_process_IFD_TAG(image_in } } } else { + if (value_ptroffset_base) { +#ifdef EXIF_DEBUG + exif_error_docref(NULL EXIFERR_CC, ImageInfo, E_NOTICE, EXIF invalid: offset_base (x%016llX) exceed value_ptr (x%016llX), offset_base, value_ptr); +#endif + return FALSE; + } /* 4 bytes or less and value is in the dir entry itself */ value_ptr = dir_entry+8; offset_val= value_ptr-offset_base; @@ -3724,6 +3731,12 @@ static int exif_process_IFD_in_TIFF(imag exif_error_docref(NULL EXIFERR_CC, ImageInfo, E_NOTICE, Next IFD: %s done, exif_get_sectionname(sub_section_index)); #endif } else { + if(dir_offset ImageInfo-file.list[sn].data) { +#ifdef EXIF_DEBUG + exif_error_docref(NULL EXIFERR_CC, ImageInfo, E_NOTICE, Skip processing: dir_offset (x%016llX) exceeds data pointer (x%016llX), ImageInfo-file.list[sn].data, dir_offset); +#endif + return FALSE; + } if (!exif_process_IFD_TAG(ImageInfo, (char*)dir_entry, (char*)(ImageInfo-file.list[sn].data-dir_offset), ifd_size, 0, section_index, 0, tag_table TSRMLS_CC)) { Previous Comments: [2012-12-12 12:33:03] dessander at gmail dot com Same situation with file: http://dl.dropbox.com/u/7562584/Bugs/Php/bad_exif.jpeg [2012-10-30 13:26:09] alex at bartl dot net seeing the same issue on php-5.4.7-10.fc17.x86_64 (Fedora 17) [2012-09-14 17:25:50] info at getid3 dot org I am also seeing the same problem on Windows (7-64-pro) running php-5.4.7-nts-Win32-VC9-x86 (and previously same thing on v5.4.4) I have only encountered one of my own files that causes the crash: http://getid3.org/temp/62523.jpg [2012-07-11 03:35:59] larue...@php.net Rasmus, could you please look at this one? I have no enough knowledge of the exif things :) [2012-07-11 03:33:59] larue...@php.net I can reproduce this only in 5.3, seems 5.3 and 5.4 have the same exif code, but can not reproduce this in 5.4. #0 0x2b6649bdd8fe in php_ifd_get16u (value=0xcc675e60, motorola_intel=0) at /home/huixinchen/opensource/php-5.3/ext/exif/exif.c:1095 1095
[PHP-BUG] Bug #64889 [NEW]: printf inconsistent parsing format string
From: xoneca+phpbugs at gmail dot com Operating system: Linux 2.6.32-46-generic PHP version: 5.3.25 Package: Scripting Engine problem Bug Type: Bug Bug description:printf inconsistent parsing format string Description: `printf` is inconsistent parsing the format string. Sometimes it throws a warning, and sometimes does not. `printf` doesn't seem to like very much single `%` chars and gets crazy. Depending on the arguments number, it will print something, or nothing. Test script: --- printf( '% % % %'); // or echo sprintf(...); printf( '% % % %', 10); printf( '% % % %', 10, 20); printf( '% % % %', 10, 20, 30); printf( '% % % %', 10, 20, 30, 40); printf( '% % % %', 10, 20, 30, 40, 50); // Another example: printf( '% ## %d ## % ## %d ## %d', 10, 20, 30, 40, 50); Expected result: Throwing a warning at each call, or none at all. But not only sometimes. Actual result: -- php printf( '% % % %'); PHP Warning: printf(): Too few arguments in php shell code on line 1 php printf( '% % % %', 10); PHP Warning: printf(): Too few arguments in php shell code on line 1 php printf( '% % % %', 10, 20); % % php printf( '% % % %', 10, 20, 30); % % php printf( '% % % %', 10, 20, 30, 40); % % php printf( '% % % %', 10, 20, 30, 40, 50); % % php // Another example: php echo sprintf( '% ## %d ## % ## %d ## %d', 10, 20, 30, 40, 50); # 20 ## # 40 ## 50 -- Edit bug report at https://bugs.php.net/bug.php?id=64889edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64889r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64889r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64889r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64889r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64889r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64889r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64889r=needscript Try newer version: https://bugs.php.net/fix.php?id=64889r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64889r=support Expected behavior: https://bugs.php.net/fix.php?id=64889r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64889r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64889r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64889r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64889r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64889r=dst IIS Stability: https://bugs.php.net/fix.php?id=64889r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64889r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64889r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64889r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64889r=mysqlcfg
Bug #64889 [Opn]: printf inconsistent parsing format string
Edit report at https://bugs.php.net/bug.php?id=64889edit=1 ID: 64889 User updated by:xoneca+phpbugs at gmail dot com Reported by:xoneca+phpbugs at gmail dot com Summary:printf inconsistent parsing format string Status: Open Type: Bug Package:Scripting Engine problem Operating System: Linux 2.6.32-46-generic -PHP Version:5.3.25 +PHP Version:5.4.15 Block user comment: N Private report: N New Comment: Tested on latest stable and the result was the same. Previous Comments: [2013-05-21 15:21:33] xoneca+phpbugs at gmail dot com Description: `printf` is inconsistent parsing the format string. Sometimes it throws a warning, and sometimes does not. `printf` doesn't seem to like very much single `%` chars and gets crazy. Depending on the arguments number, it will print something, or nothing. Test script: --- printf( '% % % %'); // or echo sprintf(...); printf( '% % % %', 10); printf( '% % % %', 10, 20); printf( '% % % %', 10, 20, 30); printf( '% % % %', 10, 20, 30, 40); printf( '% % % %', 10, 20, 30, 40, 50); // Another example: printf( '% ## %d ## % ## %d ## %d', 10, 20, 30, 40, 50); Expected result: Throwing a warning at each call, or none at all. But not only sometimes. Actual result: -- php printf( '% % % %'); PHP Warning: printf(): Too few arguments in php shell code on line 1 php printf( '% % % %', 10); PHP Warning: printf(): Too few arguments in php shell code on line 1 php printf( '% % % %', 10, 20); % % php printf( '% % % %', 10, 20, 30); % % php printf( '% % % %', 10, 20, 30, 40); % % php printf( '% % % %', 10, 20, 30, 40, 50); % % php // Another example: php echo sprintf( '% ## %d ## % ## %d ## %d', 10, 20, 30, 40, 50); # 20 ## # 40 ## 50 -- Edit this bug report at https://bugs.php.net/bug.php?id=64889edit=1
Bug #62523 [Asn]: php crashes with segfault when exif_read_data called
Edit report at https://bugs.php.net/bug.php?id=62523edit=1 ID: 62523 User updated by:bigbug at mafia dot lv Reported by:bigbug at mafia dot lv Summary:php crashes with segfault when exif_read_data called Status: Assigned Type: Bug Package:Reproducible crash Operating System: linux PHP Version:5.3Git-2012-07-10 (snap) Assigned To:rasmus Block user comment: N Private report: N New Comment: Thanks! The patch really works! Previous Comments: [2013-05-21 14:20:58] dominic dot benson at thirdlight dot com I encountered a similar issue reading EXIF from a TIFF, the below patch fixes both my original TIFF issue, and the issue with file 1.orig.jpg linked in the original report for me. Environment: Linux amd64/i686 (Debian 5/6/7, Ubuntu 13.04) PHP version: 5.3.25 SAPI: CLI/FastCGI Required for the JPEG fix is a change from int type for offset_diff in exif_process_IFD_in_MAKERNOTE. I've changed it to size_t, which is semantically correct for Linux, but I think this isn't portable to Win. Essentially, the issue is that values read from the file are treated as offsets, and used to manipulate the offset_base. Patch (agains 5.3.25) follows: diff -rupN php-5.3.25.orig/ext/exif/exif.c php-5.3.25/ext/exif/exif.c --- php-5.3.25.orig/ext/exif/exif.c 2013-05-08 16:58:52.0 +0100 +++ php-5.3.25/ext/exif/exif.c 2013-05-21 14:59:59.579438565 +0100 @@ -2745,7 +2745,8 @@ static int exif_process_unicode(image_in static int exif_process_IFD_in_MAKERNOTE(image_info_type *ImageInfo, char * value_ptr, int value_len, char *offset_base, size_t IFDlength, size_t displacement TSRMLS_DC) { int de, i=0, section_index = SECTION_MAKERNOTE; - int NumDirEntries, old_motorola_intel, offset_diff; + int NumDirEntries, old_motorola_intel; + size_t offset_diff; const maker_note_type *maker_note; char *dir_start; @@ -2921,6 +2922,12 @@ static int exif_process_IFD_TAG(image_in } } } else { + if (value_ptroffset_base) { +#ifdef EXIF_DEBUG + exif_error_docref(NULL EXIFERR_CC, ImageInfo, E_NOTICE, EXIF invalid: offset_base (x%016llX) exceed value_ptr (x%016llX), offset_base, value_ptr); +#endif + return FALSE; + } /* 4 bytes or less and value is in the dir entry itself */ value_ptr = dir_entry+8; offset_val= value_ptr-offset_base; @@ -3724,6 +3731,12 @@ static int exif_process_IFD_in_TIFF(imag exif_error_docref(NULL EXIFERR_CC, ImageInfo, E_NOTICE, Next IFD: %s done, exif_get_sectionname(sub_section_index)); #endif } else { + if(dir_offset ImageInfo-file.list[sn].data) { +#ifdef EXIF_DEBUG + exif_error_docref(NULL EXIFERR_CC, ImageInfo, E_NOTICE, Skip processing: dir_offset (x%016llX) exceeds data pointer (x%016llX), ImageInfo-file.list[sn].data, dir_offset); +#endif + return FALSE; + } if (!exif_process_IFD_TAG(ImageInfo, (char*)dir_entry, (char*)(ImageInfo-file.list[sn].data-dir_offset), ifd_size, 0, section_index, 0, tag_table TSRMLS_CC)) { [2012-12-12 12:33:03] dessander at gmail dot com Same situation with file: http://dl.dropbox.com/u/7562584/Bugs/Php/bad_exif.jpeg [2012-10-30 13:26:09] alex at bartl dot net seeing the same issue on php-5.4.7-10.fc17.x86_64 (Fedora 17) [2012-09-14 17:25:50] info at getid3 dot org I am also seeing the same problem on Windows (7-64-pro) running php-5.4.7-nts-Win32-VC9-x86 (and previously same thing on v5.4.4) I have only encountered one of my own files that causes the crash: http://getid3.org/temp/62523.jpg [2012-07-11 03:35:59] larue...@php.net Rasmus, could you please look at this one? I have no enough knowledge of the exif things :) 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
[PHP-BUG] Bug #64890 [NEW]: strrpos with negative offset incorrect results
From: me at rouvenwessling dot de Operating system: OS X PHP version: 5.4.15 Package: Strings related Bug Type: Bug Bug description:strrpos with negative offset incorrect results Description: Apparently the offset in strrpos doesn't work right if it's the same as the needle length. Test script: --- $result = strrpos('Internationalization', 'n', -1); var_dump($result); Expected result: int(10) Actual result: -- int(19) -- Edit bug report at https://bugs.php.net/bug.php?id=64890edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64890r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64890r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64890r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64890r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64890r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64890r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64890r=needscript Try newer version: https://bugs.php.net/fix.php?id=64890r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64890r=support Expected behavior: https://bugs.php.net/fix.php?id=64890r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64890r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64890r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64890r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64890r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64890r=dst IIS Stability: https://bugs.php.net/fix.php?id=64890r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64890r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64890r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64890r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64890r=mysqlcfg
Bug #64891 [Nab]: POST values in Google Chrome XHR.
Edit report at https://bugs.php.net/bug.php?id=64891edit=1 ID: 64891 User updated by:marc at kryn dot org Reported by:marc at kryn dot org Summary:POST values in Google Chrome XHR. Status: Not a bug Type: Bug Package:Built-in web server Operating System: OS X 10.8.2 PHP Version:5.4.15 Block user comment: N Private report: N New Comment: Sorry, but you shouldn't modify the test script and then say 'it works with this modification'. I don't know what's the different in the header are to your example, but it's however not important, because mine produces a correct HTTP Request header. Google Chrome sends with my script following header: POST /test3.php?test=1 HTTP/1.1 Host: 127.0.0.1:8000 Connection: keep-alive Content-Length: 7 Cache-Control: max-age=0 Origin: http://127.0.0.1:8000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36 Content-type: application/x-www-form-urlencoded Accept: */* Referer: http://127.0.0.1:8000/test3.php Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 So it's a valid request header and should thus be handled correctly in PHP. You've mentioned a missing Content-Length: it's not missing. You've mentioned a missing charset in the Content-Type: This is not mandatory as you can read in http://tools.ietf.org/html/rfc2616#section-3.7. Please re-open this ticket, since it's still a bug on php's side and not a support question. Previous Comments: [2013-05-21 22:15:42] google...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. This doesn't appear to be a bug in PHP. It looks to me like FireFox and some other UAs will modify the request headers resulting from that javascript code to comply with the spec. Chrome seems to be sending a request, as a result of that javascript XHR, that is missing both the charset in the Content-type header as well as a Content- length header. If I just let the UA do the encoding and formulate the request properly through javascript I get the expected result: ?php if (isset($_GET['test'])) { echo 'received values: br/'; var_dump(file_get_contents(php://input),$_POST,$_GET); exit; } ? div id=response/div form id=myform input name=foo value=bar type=text / /form script var xhr = new XMLHttpRequest(); xhr.open('POST', '?= $_SERVER['SCRIPT_NAME'] ??test=1', true); xhr.onload = function(){ document.getElementById('response').innerHTML = this.responseText; }; var frm = new FormData(document.getElementById(myform)); xhr.send(frm); /script This works for me in all the latest versions of Chrome, FireFox, Opera, Safari, and IE. Please feel free to reopen this bug report if you have additional evidence of a bug in PHP. [2013-05-21 21:24:06] marc at kryn dot org Description: The PHP file servered through the built-int web server does not receive somehow the POST values from a AJAX/XHR POST call in Google Chrome. Only in Google Chrome. Setup: - Create the file from the test script. - Open a built-in web server `php54 -S 127.0.0.1:8000 -t web/` - Open the file `http://127.0.0.1:8000/test.php` This behaviour happens only for the built-in web server and Google Chrome. It works fine when running PHP behind fpm or as apache module. Any other browser works in all combinations (built-in server or not). Tested on `5.4.15-1` installed through mac ports. Test script: --- ?php if (isset($_GET['test'])) { echo 'received values: br/'; var_dump($_POST); exit; } ? div id=response/div script var xhr = new XMLHttpRequest(); xhr.open('POST', '?= $_SERVER['SCRIPT_NAME'] ??test=1', true); xhr.setRequestHeader(Content-type, application/x-www-form-urlencoded); xhr.onload = function(){ document.getElementById('response').innerHTML = this.responseText; }; xhr.send('foo=bar'); /script Expected result: received values: array (size=1) 'foo' = string 'bar' (length=3) Actual result: -- received values: array (size=0) empty -- Edit this bug report at https://bugs.php.net/bug.php?id=64891edit=1
[PHP-BUG] Bug #64893 [NEW]: Crash due to dtor call happening after dtor shutdown
From: nikic Operating system: PHP version: 5.5.0RC1 Package: Scripting Engine problem Bug Type: Bug Bug description:Crash due to dtor call happening after dtor shutdown Description: If an object is created *after* the destructor shutdown, its dtor will be called when it is freed, which potentially happens during a phase of the shutdown process where the executor is no longer in a consistent state. The test script uses the ob callback (called after dtor shutdown) to create an object and bind it to to the error callback, which is later freed during zend_deactivate, as part of the executor shutdown. Result: /home/nikic/dev/php-dev/Zend/zend_hash.c(946) : ht=0x42dea5c is already destroyed Test script: --- ?php ob_start(function() { $foo = new Foo; set_error_handler(function() use ($foo) {}); }); class Foo { public function __destruct() { var_dump($GLOBALS); } } -- Edit bug report at https://bugs.php.net/bug.php?id=64893edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64893r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64893r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64893r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64893r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64893r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64893r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64893r=needscript Try newer version: https://bugs.php.net/fix.php?id=64893r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64893r=support Expected behavior: https://bugs.php.net/fix.php?id=64893r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64893r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64893r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64893r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64893r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64893r=dst IIS Stability: https://bugs.php.net/fix.php?id=64893r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64893r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64893r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64893r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64893r=mysqlcfg
Bug #64815 [Fbk-Opn]: Rendering some image broken
Edit report at https://bugs.php.net/bug.php?id=64815edit=1 ID: 64815 User updated by:adrianbjones at gmail dot com Reported by:adrianbjones at gmail dot com Summary:Rendering some image broken -Status: Feedback +Status: Open Type: Bug Package:GD related Operating System: Debian PHP Version:5.4.15 Block user comment: N Private report: N New Comment: OK, finally figured out the issue with this, Sorry, it's not a PHP bug at all. There is a regex in PEAR Image_Canvas that looks for the version of GD. The new version of GD 2.1.0 was being matched by a poorly written regex that looked for version 1.x first. Image_Canvas only uses ImageCreateTrueColor if GD is version 2.x, hence the color/transparency issues. Anyway, all sorted now - I will file a bug with Image_Canvas, even though it is no longer being maintained. Sorry to trouble you! Previous Comments: [2013-05-16 19:44:52] ahar...@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 ?php and ends 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. A reproduction script using GD directly would be extremely helpful, along with the configure lines used both in PHP 5.4.14 and 5.4.15 and any difference in libpng versions, please. [2013-05-10 18:07:37] adrianbjones at gmail dot com Description: I am using PEAR Image_Canvas to dynamically generate some images. The same script has worked from PHP 4.x all the way through to 5.4.14. Basically the script layers several transparent png files together to make a combined image I just upgraded to 5.4.15 and the images are no longing rendering properly. Certain elements are replaced by solid rectangles and others have a variety of color changes. It seems like it might be a transparency issue with PNG files, but not sure. Reverting to 5.4.14 instantly fixes the images. -- Edit this bug report at https://bugs.php.net/bug.php?id=64815edit=1
Bug #64891 [Nab]: POST values in Google Chrome XHR.
Edit report at https://bugs.php.net/bug.php?id=64891edit=1 ID: 64891 Updated by: google...@php.net Reported by:marc at kryn dot org Summary:POST values in Google Chrome XHR. Status: Not a bug Type: Bug Package:Built-in web server Operating System: OS X 10.8.2 PHP Version:5.4.15 Block user comment: N Private report: N New Comment: Well, first of all you're linking to the wrong part of the RFC when you're referring to the character encoding of the HTTP request header. There is undefined behavior according to the spec and you can see that here http://tools.ietf.org/html/rfc2616#section-3.4.1 where it clearly says: Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean recipient should guess. Senders wishing to defeat this behavior MAY include a charset parameter even when the charset is ISO-8859-1 and SHOULD do so when it is known that it will not confuse the recipient. Unfortunately, some older HTTP/1.0 clients did not deal properly with an explicit charset parameter. HTTP/1.1 recipients MUST respect the charset label provided by the sender; and those user agents that have a provision to guess a charset MUST use the charset from the Content coding values indicate an encoding transformation that has been or can be applied to an entity. Content codings are primarily used to allow a document to be compressed or otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Frequently, the entity is stored in coded form, transmitted directly, and only decoded by the recipient. So with that said if I go ahead and add the charset to the request header in your script I get the expected result. ?php if (isset($_GET['test'])) { echo 'received values: br/'; var_dump($_POST); exit; } ? div id=response/div script var xhr = new XMLHttpRequest(); xhr.open('POST', '?= $_SERVER['SCRIPT_NAME'] ??test=1', true); xhr.setRequestHeader(Content-type, application/x-www-form-urlencoded; charset=UTF- 8); xhr.onload = function(){ document.getElementById('response').innerHTML = this.responseText; }; xhr.send(foo=bar); /script You can see that by reviewing the Request Headers from both FireFox and Chrome with your developer tools that FireFox appends the charset=UTF-8 to the Content-type header for you, whereas Chrome does not (you can see that from your supplied request header). Previous Comments: [2013-05-21 22:35:13] marc at kryn dot org Sorry, but you shouldn't modify the test script and then say 'it works with this modification'. I don't know what's the different in the header are to your example, but it's however not important, because mine produces a correct HTTP Request header. Google Chrome sends with my script following header: POST /test3.php?test=1 HTTP/1.1 Host: 127.0.0.1:8000 Connection: keep-alive Content-Length: 7 Cache-Control: max-age=0 Origin: http://127.0.0.1:8000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36 Content-type: application/x-www-form-urlencoded Accept: */* Referer: http://127.0.0.1:8000/test3.php Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 So it's a valid request header and should thus be handled correctly in PHP. You've mentioned a missing Content-Length: it's not missing. You've mentioned a missing charset in the Content-Type: This is not mandatory as you can read in http://tools.ietf.org/html/rfc2616#section-3.7. Please re-open this ticket, since it's still a bug on php's side and not a support question. [2013-05-21 22:15:42] google...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. This doesn't appear to be a bug in PHP. It looks to me like FireFox and some other UAs will modify the request headers resulting from that javascript code to comply with the spec. Chrome seems to be sending a request, as a result of that javascript XHR, that is missing both the charset in the Content-type header as well as a Content- length header. If I just let the UA do the encoding and formulate the request properly through javascript I get the expected result: ?php if (isset($_GET['test'])) { echo 'received values: br/';
Bug #64890 [Com]: strrpos with negative offset incorrect results
Edit report at https://bugs.php.net/bug.php?id=64890edit=1 ID: 64890 Comment by: cmbecker69 at gmx dot de Reported by:me at rouvenwessling dot de Summary:strrpos with negative offset incorrect results Status: Open Type: Bug Package:Strings related Operating System: OS X PHP Version:5.4.15 Block user comment: N Private report: N New Comment: The issue occurs for negative offsets, when the length of the needle is less than or equal to the absolute value of the offset. The cause seems to be in ext/standard/string.c line 1958: e = haystack + haystack_len + offset; This lets e reference one character further to the right than it actually should. Changing this line to: e = haystack + haystack_len + offset - 1; fixes the issue and gives the expected result for the test script. Previous Comments: [2013-05-21 17:53:36] me at rouvenwessling dot de Description: Apparently the offset in strrpos doesn't work right if it's the same as the needle length. Test script: --- $result = strrpos('Internationalization', 'n', -1); var_dump($result); Expected result: int(10) Actual result: -- int(19) -- Edit this bug report at https://bugs.php.net/bug.php?id=64890edit=1
Bug #64891 [Nab]: POST values in Google Chrome XHR.
Edit report at https://bugs.php.net/bug.php?id=64891edit=1 ID: 64891 User updated by:marc at kryn dot org Reported by:marc at kryn dot org Summary:POST values in Google Chrome XHR. Status: Not a bug Type: Bug Package:Built-in web server Operating System: OS X 10.8.2 PHP Version:5.4.15 Block user comment: N Private report: N New Comment: First of all: You've copypasted a not existing paragraph/mixed sentences to a complete new paragraph. Your quote does not exist in that RFC! The correct one is: Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean recipient should guess. Senders wishing to defeat this behavior MAY include a charset parameter even when the charset is ISO-8859-1 and SHOULD do so when it is known that it will not confuse the recipient. Unfortunately, some older HTTP/1.0 clients did not deal properly with an explicit charset parameter. HTTP/1.1 recipients MUST respect the charset label provided by the sender; and those user agents that have a provision to guess a charset MUST use the charset from the content-type field if they support that charset, rather than the recipient's preference, when initially displaying a document. See section 3.7.1. And here again: it says 'MAY' and 'SHOULD', and not 'MUST', thus the charset is optional (MAY) and max recommended (SHOULD) IF we know the charset. All as already mentioned in http://tools.ietf.org/html/rfc2616#section-3.7. The only sentence with a MUST ... and those user agents that have a provision to guess a charset MUST use the charset from the content-type field if they support that charset, rather than the recipient's preference, when initially displaying a document. ... is not important here, since it's about the Response header. We're talking about the opposite. And here is what PHP should probably do: http://tools.ietf.org/html/rfc2616#section-3.7.1 When no explicit charset parameter is provided by the sender, media subtypes of the text type are defined to have a default charset value of ISO-8859-1 when received via HTTP. I know now that other browsers add the Charset part to the Content-Type, but that's however not important, since it's not a MUST regarding the RFC. The PHP built-in web server should handle also requests without a charset and assume that the text body of request without a defined charset is a ISO-8859-1. The strange behaviour is that PHP _does_ parse the Request infrequently correct, but mostly not. Previous Comments: [2013-05-21 22:59:47] google...@php.net Well, first of all you're linking to the wrong part of the RFC when you're referring to the character encoding of the HTTP request header. There is undefined behavior according to the spec and you can see that here http://tools.ietf.org/html/rfc2616#section-3.4.1 where it clearly says: Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean recipient should guess. Senders wishing to defeat this behavior MAY include a charset parameter even when the charset is ISO-8859-1 and SHOULD do so when it is known that it will not confuse the recipient. Unfortunately, some older HTTP/1.0 clients did not deal properly with an explicit charset parameter. HTTP/1.1 recipients MUST respect the charset label provided by the sender; and those user agents that have a provision to guess a charset MUST use the charset from the Content coding values indicate an encoding transformation that has been or can be applied to an entity. Content codings are primarily used to allow a document to be compressed or otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Frequently, the entity is stored in coded form, transmitted directly, and only decoded by the recipient. So with that said if I go ahead and add the charset to the request header in your script I get the expected result. ?php if (isset($_GET['test'])) { echo 'received values: br/'; var_dump($_POST); exit; } ? div id=response/div script var xhr = new XMLHttpRequest(); xhr.open('POST', '?= $_SERVER['SCRIPT_NAME'] ??test=1', true); xhr.setRequestHeader(Content-type, application/x-www-form-urlencoded; charset=UTF- 8); xhr.onload = function(){ document.getElementById('response').innerHTML = this.responseText; }; xhr.send(foo=bar); /script You can see that by reviewing the Request Headers from both FireFox and Chrome with your developer tools that FireFox appends the charset=UTF-8 to the Content-type header for you, whereas Chrome does not (you can see that from your
[PHP-BUG] Req #64894 [NEW]: information about speed
From: roberto at spadim dot com dot br Operating system: linux PHP version: 5.4.15 Package: *General Issues Bug Type: Feature/Change Request Bug description:information about speed Description: hi guys, could anyone explain this results? why a $array['string'] is slower to ++ operator and $array[0] and $class- variable and $single_var and why a $var that point to anyone of this type of var $point=$to_this_var; is faster than anyone? Test script: --- ?php class a{ var $t; } $array=array(0=0,'t'=0); $var=0; $class=new a; $qnt=1000; $t1=microtime(1); for($i=0;$i$qnt;$i++) $array['t']++; $t2=microtime(1); for($i=0;$i$qnt;$i++) $array[0]++; $t3=microtime(1); for($i=0;$i$qnt;$i++) $class-t++; $t4=microtime(1); for($i=0;$i$qnt;$i++) $var++; $t5=microtime(1); echoarray with string index: .($t2-$t1).\n. array with number index: .($t3-$t2).\n. class public var: .($t4-$t3).\n. var: .($t5-$t4).\n. ''; $array=array(0=0,'t'=0); $var=0; $class=new a; $qnt=1000; $v1=$array['t']; $v2=$array[0]; $v3=$a-t; $v4=$var; $t1=microtime(1); for($i=0;$i$qnt;$i++) $v1++; $t2=microtime(1); for($i=0;$i$qnt;$i++) $v2++; $t3=microtime(1); for($i=0;$i$qnt;$i++) $v3++; $t4=microtime(1); for($i=0;$i$qnt;$i++) $v4++; $t5=microtime(1); echo array with string index: .($t2-$t1).\n. array with number index: .($t3-$t2).\n. class public var: .($t4-$t3).\n. var: .($t5-$t4).\n. ''; Expected result: array with string index: 0.80007791519165(at least sabe time as $array[0]) array with number index: 0.65114402770996(why not faster like $var?) class public var: 0.5907871723175(why not faster like $var?) var: 0.47185897827148(why not faster like $var?) array with string index: 0.46768593788147 (why faster than a $var?!?!?!?!) array with number index: 0.46670913696289 class public var: 0.46836400032043 var: 0.46757102012634 Actual result: -- array with string index: 0.80007791519165 array with number index: 0.65114402770996 class public var: 0.5907871723175 var: 0.47185897827148 array with string index: 0.46768593788147 array with number index: 0.46670913696289 class public var: 0.46836400032043 var: 0.46757102012634 system is only running me, it's linux with php, nothing less, nothing more downloaded slackware and php -- Edit bug report at https://bugs.php.net/bug.php?id=64894edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64894r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64894r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64894r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64894r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64894r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64894r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64894r=needscript Try newer version: https://bugs.php.net/fix.php?id=64894r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64894r=support Expected behavior: https://bugs.php.net/fix.php?id=64894r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64894r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64894r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64894r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64894r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64894r=dst IIS Stability: https://bugs.php.net/fix.php?id=64894r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64894r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64894r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64894r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64894r=mysqlcfg
Req #64894 [Opn-Nab]: information about speed
Edit report at https://bugs.php.net/bug.php?id=64894edit=1 ID: 64894 Updated by: s...@php.net Reported by:roberto at spadim dot com dot br Summary:information about speed -Status: Open +Status: Not a bug Type: Feature/Change Request Package:*General Issues Operating System: linux PHP Version:5.4.15 Block user comment: N Private report: N New Comment: Please use an appropriate mail list to ask questions: http://php.net/mailing-lists.php Previous Comments: [2013-05-22 02:51:08] roberto at spadim dot com dot br Description: hi guys, could anyone explain this results? why a $array['string'] is slower to ++ operator and $array[0] and $class- variable and $single_var and why a $var that point to anyone of this type of var $point=$to_this_var; is faster than anyone? Test script: --- ?php class a{ var $t; } $array=array(0=0,'t'=0); $var=0; $class=new a; $qnt=1000; $t1=microtime(1); for($i=0;$i$qnt;$i++) $array['t']++; $t2=microtime(1); for($i=0;$i$qnt;$i++) $array[0]++; $t3=microtime(1); for($i=0;$i$qnt;$i++) $class-t++; $t4=microtime(1); for($i=0;$i$qnt;$i++) $var++; $t5=microtime(1); echoarray with string index: .($t2-$t1).\n. array with number index: .($t3-$t2).\n. class public var: .($t4-$t3).\n. var: .($t5-$t4).\n. ''; $array=array(0=0,'t'=0); $var=0; $class=new a; $qnt=1000; $v1=$array['t']; $v2=$array[0]; $v3=$a-t; $v4=$var; $t1=microtime(1); for($i=0;$i$qnt;$i++) $v1++; $t2=microtime(1); for($i=0;$i$qnt;$i++) $v2++; $t3=microtime(1); for($i=0;$i$qnt;$i++) $v3++; $t4=microtime(1); for($i=0;$i$qnt;$i++) $v4++; $t5=microtime(1); echo array with string index: .($t2-$t1).\n. array with number index: .($t3-$t2).\n. class public var: .($t4-$t3).\n. var: .($t5-$t4).\n. ''; Expected result: array with string index: 0.80007791519165(at least sabe time as $array[0]) array with number index: 0.65114402770996(why not faster like $var?) class public var: 0.5907871723175(why not faster like $var?) var: 0.47185897827148(why not faster like $var?) array with string index: 0.46768593788147 (why faster than a $var?!?!?!?!) array with number index: 0.46670913696289 class public var: 0.46836400032043 var: 0.46757102012634 Actual result: -- array with string index: 0.80007791519165 array with number index: 0.65114402770996 class public var: 0.5907871723175 var: 0.47185897827148 array with string index: 0.46768593788147 array with number index: 0.46670913696289 class public var: 0.46836400032043 var: 0.46757102012634 system is only running me, it's linux with php, nothing less, nothing more downloaded slackware and php -- Edit this bug report at https://bugs.php.net/bug.php?id=64894edit=1
Req #64894 [Nab]: information about speed
Edit report at https://bugs.php.net/bug.php?id=64894edit=1 ID: 64894 User updated by:roberto at spadim dot com dot br Reported by:roberto at spadim dot com dot br Summary:information about speed Status: Not a bug Type: Feature/Change Request Package:*General Issues Operating System: linux PHP Version:5.4.15 Block user comment: N Private report: N New Comment: there's a benchmark list? Previous Comments: [2013-05-22 04:44:42] s...@php.net Please use an appropriate mail list to ask questions: http://php.net/mailing-lists.php [2013-05-22 02:51:08] roberto at spadim dot com dot br Description: hi guys, could anyone explain this results? why a $array['string'] is slower to ++ operator and $array[0] and $class- variable and $single_var and why a $var that point to anyone of this type of var $point=$to_this_var; is faster than anyone? Test script: --- ?php class a{ var $t; } $array=array(0=0,'t'=0); $var=0; $class=new a; $qnt=1000; $t1=microtime(1); for($i=0;$i$qnt;$i++) $array['t']++; $t2=microtime(1); for($i=0;$i$qnt;$i++) $array[0]++; $t3=microtime(1); for($i=0;$i$qnt;$i++) $class-t++; $t4=microtime(1); for($i=0;$i$qnt;$i++) $var++; $t5=microtime(1); echoarray with string index: .($t2-$t1).\n. array with number index: .($t3-$t2).\n. class public var: .($t4-$t3).\n. var: .($t5-$t4).\n. ''; $array=array(0=0,'t'=0); $var=0; $class=new a; $qnt=1000; $v1=$array['t']; $v2=$array[0]; $v3=$a-t; $v4=$var; $t1=microtime(1); for($i=0;$i$qnt;$i++) $v1++; $t2=microtime(1); for($i=0;$i$qnt;$i++) $v2++; $t3=microtime(1); for($i=0;$i$qnt;$i++) $v3++; $t4=microtime(1); for($i=0;$i$qnt;$i++) $v4++; $t5=microtime(1); echo array with string index: .($t2-$t1).\n. array with number index: .($t3-$t2).\n. class public var: .($t4-$t3).\n. var: .($t5-$t4).\n. ''; Expected result: array with string index: 0.80007791519165(at least sabe time as $array[0]) array with number index: 0.65114402770996(why not faster like $var?) class public var: 0.5907871723175(why not faster like $var?) var: 0.47185897827148(why not faster like $var?) array with string index: 0.46768593788147 (why faster than a $var?!?!?!?!) array with number index: 0.46670913696289 class public var: 0.46836400032043 var: 0.46757102012634 Actual result: -- array with string index: 0.80007791519165 array with number index: 0.65114402770996 class public var: 0.5907871723175 var: 0.47185897827148 array with string index: 0.46768593788147 array with number index: 0.46670913696289 class public var: 0.46836400032043 var: 0.46757102012634 system is only running me, it's linux with php, nothing less, nothing more downloaded slackware and php -- Edit this bug report at https://bugs.php.net/bug.php?id=64894edit=1