Bug #62789 [Com]: Autoloaders are invoked with invalid class names
Edit report at https://bugs.php.net/bug.php?id=62789&edit=1 ID: 62789 Comment by: victor dot berchet at sensiolabs dot com Reported by:drak at zikula dot org Summary:Autoloaders are invoked with invalid class names Status: Open Type: Bug Package:SPL related PHP Version:5.3.15 Block user comment: N Private report: N New Comment: As indicated in the blog post linked in the issue report, a few functions are affected (ie they can trigger the autoload function with an invalid class name): - class_exists() - interface_exists() - class_parents() - class_implements() - is_subclass_of() Previous Comments: [2012-08-09 20:04:23] drak at zikula dot org Description: It is possible to invoke class autoloaders with invalid class names leading to potential security issues. Classes can contain alphaumeric, underscore and backslash characters. However, code like: $foo = new $class where $class might contain any arbitrary string will cause the autoloader stack to be called even if the $class variable contained invalid characters for a class name. This could lead to various file inclusion issues as detailed in http://drak3.devmx.de/blog/2012/08/08/autoloaded-remote-file-inclusion/ However, it is not reasonable for classloaders to validate the class name passed to it via PHP for valid classname characters. Doing so would be an incredible burden on performance ever increasing with the size of the autoloader stack. I suggest that PHP validate the characters of the class before deciding to call the autoloader stack or not. -- Edit this bug report at https://bugs.php.net/bug.php?id=62789&edit=1
Req #53866 [Com]: Zend engine's hashtable performance tweaks
Edit report at https://bugs.php.net/bug.php?id=53866&edit=1 ID: 53866 Comment by: reeze dot xia at gmail dot com Reported by:marcin dot babij at nasza-klasa dot pl Summary:Zend engine's hashtable performance tweaks Status: Assigned Type: Feature/Change Request Package:Scripting Engine problem PHP Version:trunk-SVN-2011-01-28 (SVN) Assigned To:dmitry Block user comment: N Private report: N New Comment: This seems dead. no response for a long time :( Previous Comments: [2011-01-28 13:27:48] marcin dot babij at nasza-klasa dot pl Description: What was done: - Hash function in zend_hash.h was rebuilt and became much faster, without losing the most important properties. - Hashtable implementation was changed from Simple chaining to Open addressing with linear probing, but with linked bucket, not included in hash array, which causes: -- Bucket structure to lose 2 pointers. -- Searching works similar, but don't have to jump with pointers stored in different memory locations, inserting, deleting and rehashing don't need to update linked list, but must search for first empty bucket, which is fast, because it scans continuous memory. -- Load factor decreases from 1.0 to 0.5-0.75 to make less collisions and faster hashtable, which in turn increases memory footprint a little. - Open addressing doesn't change significantly performance, but next thing was to create new array (arEmpty), which is of size nTableSize bytes, which keeps track of used/empty buckets and makes inserting and rehashing much faster. In future it can be tested as bit-array with size of nTableSize/8 bytes. - More macros were added to replace repetitive constructs. - New constants were added to allow: -- Creating new hashtables of size at least X (where 4 and 8 are reasonable), which makes no rehashing and reallocing memory while changing size to 2 and then to 4. -- For small tables it's better to extend them by a factor of 4 times, not 2, to make rehashing cost smaller for most hashtables, of cost of little higher memory consumption. -- For large tables it's better to have other load factor, closer to 1, while for small tables it's better to use load factor closer to 0.5. What should be done: - http://lxr.php.net/xref/PHP_TRUNK/ext/standard/html_tables/html_table_gen.php#722 should be changed and html_tables.h regenerated, but this will need to rewrite hashtable engine from C to PHP - APC should be fixed What can be done: - Make new constants configurable by php.ini. - Test if changing arEmpty from byte-array to bit-array helps on performance. - Tweak default constants' values using some real-live benchmarks. - Prove (or modify and prove) hash function to have property, that it has no collisions if two keys don't differ on no more than 6 bytes, which will lead to memcmp omit first (or last) 6 bytes of key. Also simpler thing may be proven, that is it has no collisions if two keys are not longer than 6 bytes, which will make most string keys omit memcpy at all. -- Edit this bug report at https://bugs.php.net/bug.php?id=53866&edit=1
Bug #62328 [Com]: implementing __toString and a cast to string fails
Edit report at https://bugs.php.net/bug.php?id=62328&edit=1 ID: 62328 Comment by: leight at gmail dot com Reported by:jordan dot raub at dataxltd dot com Summary:implementing __toString and a cast to string fails Status: Open Type: Bug Package:SimpleXML related Operating System: Linux PHP Version:5.4.4 Block user comment: N Private report: N New Comment: This is caused by a built-in classes cast_object function being called when it exists, before falling back to alternative methods of converting to a string. I have added a pull request that fixes the issue. https://github.com/php/php-src/pull/157 Previous Comments: [2012-06-14 19:13:55] jordan dot raub at dataxltd dot com Oops! Accidentally switched the expected and actual results... [2012-06-14 19:11:31] jordan dot raub at dataxltd dot com Description: I would expect casting to a string to have the same result as calling the __toString() function on extending a SimpleXMLElement object. I've tested this against PHP 5.3.3-7+squeeze13 with Suhosin-Patch (cli) (built: Jun 10 2012 07:31:32) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with XCache v1.3.0, Copyright (c) 2005-2009, by mOo with Xdebug v2.1.2, Copyright (c) 2002-2011, by Derick Rethans with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH and PHP 5.4.4 (cli) (built: Jun 14 2012 11:50:02) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies and PHP 5.3.14 (cli) (built: Jun 14 2012 11:49:39) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies Test script: --- '); $xml->tag = "you're it!"; echo "\nno cast\n"; echo $xml; echo "\ncast\n"; echo (string) $xml; echo "\nexplicit call\n"; echo $xml->__toString(); echo "\n"; var_dump((string) $xml); var_dump($xml->__toString()); Expected result: no cast stringification cast explicit call stringification string(0) "" string(15) "stringification" Actual result: -- no cast stringification cast stringification explicit call stringification string(15) "stringification" string(15) "stringification" -- Edit this bug report at https://bugs.php.net/bug.php?id=62328&edit=1
[PHP-BUG] Bug #62792 [NEW]: number_format with largue numbers is broken
From: brodanoel at gmail dot com Operating system: Red Hat PHP version: 5.3.15 Package: Strings related Bug Type: Bug Bug description:number_format with largue numbers is broken Description: Using the number_format function with largue numbers, the value returned is the real + 1 Test script: --- number_format(999, 0, '', '.') Expected result: 9.999.999.999.999.999.999 Actual result: -- 10.000.000.000.000.000.000 -- Edit bug report at https://bugs.php.net/bug.php?id=62792&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62792&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62792&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62792&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62792&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62792&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62792&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62792&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62792&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62792&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62792&r=support Expected behavior: https://bugs.php.net/fix.php?id=62792&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62792&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62792&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62792&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62792&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62792&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62792&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62792&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62792&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62792&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62792&r=mysqlcfg
Bug #47429 [Fbk->Nab]: Memory leak using shmop_open
Edit report at https://bugs.php.net/bug.php?id=47429&edit=1 ID: 47429 Updated by: larue...@php.net Reported by:iv dot zhekov at gmail dot com Summary:Memory leak using shmop_open -Status: Feedback +Status: Not a bug Type: Bug Package:Semaphore related Operating System: Windows XP PHP Version:5.2CVS-2009-02-17 Block user comment: N Private report: N New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Previous Comments: [2011-02-25 11:41:06] giezer at eu dot objectiflune dot com Tested this with 5.2.17 and I can still reproduce this problem it isn't fixed. [2010-08-26 00:08:29] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-02-18 09:16:15] iv dot zhekov at gmail dot com Still reproduced using latest snapshot. [2009-02-17 22:58:44] iv dot zhekov at gmail dot com Description: Function shmop_open increases memory used by Apache with about 4KB every time it is invoked, and doesn't free it. It looks like memory allocated for php_shmop struct is not freed. Reproduce code: --- Expected result: Memory used by apache should be increased only once, when shared memory segment is created. Refreshing the page should not increase used memory or it must free it when script ends. Actual result: -- Every time the script is executed additional 4KB are added to the memory used by Apache. -- Edit this bug report at https://bugs.php.net/bug.php?id=47429&edit=1
Req #36562 [Sus->Nab]: Reflection information throughout PHP
Edit report at https://bugs.php.net/bug.php?id=36562&edit=1
ID: 36562
Updated by: larue...@php.net
Reported by:justin at superglobals dot com
Summary:Reflection information throughout PHP
-Status: Suspended
+Status: Not a bug
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
PHP Version:5.*
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
Previous Comments:
[2006-02-28 20:03:18] he...@php.net
This is suspended until somebody is willing to do the work.
And of course the work has to be done throughout php.
[2006-02-28 19:52:28] justin at superglobals dot com
Description:
When you request the ReflectionParameters for the PDO constructor, it returns
an empty array instead of an array of ReflectionParamters representing the dsn,
username, password and driver options.
It would seem that PDO is not providing Reflection info for it's constructor
(possibly more).
Reproduce code:
---
$method = new ReflectionMethod ('PDO', '__construct');
print_r ($method->getParameters ());
Expected result:
Array
(
[0] => ReflectionParameter Object
(
[name] => dsn
)
[1] => ReflectionParameter Object
(
[name] => username
)
[2] => ReflectionParameter Object
(
[name] => password
)
[3] => ReflectionParameter Object
(
[name] => driver_options
)
)
Actual result:
--
Array
(
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=36562&edit=1
Bug #47284 [Ver->Nab]: Args disappear from exception stack trace (works in 5.3)
Edit report at https://bugs.php.net/bug.php?id=47284&edit=1
ID: 47284
Updated by: larue...@php.net
Reported by:the...@php.net
Summary:Args disappear from exception stack trace (works in
5.3)
-Status: Verified
+Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.2CVS-2009-04-25
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
Previous Comments:
[2009-02-09 21:23:45] the...@php.net
Doesn't help, I tried PHP 5.2 from CVS, which yields the same result:
== php -v ==
PHP 5.2.9RC2-dev (cli) (built: Feb 9 2009 08:46:53) (DEBUG)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
== Results ==
array(1) {
[0]=>
array(4) {
["file"]=>
string(17) "Command line code"
["line"]=>
int(1)
["function"]=>
string(5) "raise"
["args"]=>
array(2) {
[0]=>
string(3) "Arg"
[1]=>
string(5) "Cause"
}
}
}
array(1) {
[0]=>
array(3) {
["file"]=>
string(17) "Command line code"
["line"]=>
int(1)
["function"]=>
string(5) "raise"
}
}
[2009-02-02 22:38:33] the...@php.net
Description:
Exception's stacktraces miss the "args" key in certain situations (whereas
debug_backtrace() will report them).
Reproduce code:
---
php -r 'class Chained extends Exception { function __construct($message,
$cause) { parent::__construct($message); $this->cause= $cause; }} function
raise($message, $cause) { throw new Chained($message, new Exception($cause)); }
try { raise("Arg", "Cause"); } catch (Exception $e) { var_dump($e->getTrace(),
$e->cause->getTrace()); }'
Expected result:
Twice this:
array(1) {
[0]=>
array(4) {
["file"]=>
string(17) "Command line code"
["line"]=>
int(1)
["function"]=>
string(5) "raise"
["args"]=>
array(2) {
[0]=>
&string(3) "Arg"
[1]=>
&string(5) "Cause"
}
}
}
Actual result:
--
array(1) {
[0]=>
array(4) {
["file"]=>
string(17) "Command line code"
["line"]=>
int(1)
["function"]=>
string(5) "raise"
["args"]=>
array(2) {
[0]=>
string(3) "Arg"
[1]=>
string(5) "Cause"
}
}
}
array(1) {
[0]=>
array(3) {
["file"]=>
string(17) "Command line code"
["line"]=>
int(1)
["function"]=>
string(5) "raise"
}
}
The second array is missing the "args" key. In PHP 5.3, it's present.
--
Edit this bug report at https://bugs.php.net/bug.php?id=47284&edit=1
