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
