Req #61759 [Com]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759&edit=1
ID: 61759
Comment by: jpa...@php.net
Reported by:ahar...@php.net
Summary:class_alias() should accept classes with leading
backslashes
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Irrelevant
PHP Version:master-Git-2012-04-18 (Git)
Block user comment: N
Private report: N
New Comment:
Johannes: I agree, but we could start by patching this bug report right?
I got a patch here : https://github.com/jpauli/php-
src/compare/class_alias_registration_fix
Previous Comments:
[2013-08-26 18:32:26] johan...@php.net
Note: The bug report is too restrictive. A proper patch would have to work on
all places where classnames come from string context. This at first means
verifying that all places go via zend_lookup_class() and related functions, not
EG(class_table) / CG(class_table)
[2013-08-26 18:13:08] contact at jubianchi dot fr
I experienced the exact same issue on PHP 5.4.17 on OS X 10.9 (Mavericks DP6).
I wrote a simple test case, here it is :
Test script:
---
namespace jubianchi\Alias {
class A {}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'C'));
$reflector = new \ReflectionClass('C');
var_dump($reflector->getName());
var_dump(class_alias('\\jubianchi\\Alias\\A', '\\jubianchi\\Alias\\B'));
try {
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector->getName());
} catch(\Exception $e) {
var_dump(get_class($e) . ': ' . $e->getMessage());
}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'jubianchi\\Alias\\B'));
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector->getName());
}
Expected result:
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(17) "jubianchi\Alias\A"
Or:
bool(true)
string(17) "jubianchi\Alias\A"
bool(false)
string(60) "ReflectionException: Class \jubianchi\Alias\B does not exist"
bool(true)
string(17) "jubianchi\Alias\A"
Actual result:
bool(true)
string(1) "A"
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(60) "ReflectionException: Class \jubianchi\Alias\B does not exist"
bool(true)
string(17) "jubianchi\Alias\A"
As you can see, class_alias returns bool(true) as if everything went fine, so
we
expect the alias to be available but a reflection on the latter throws an
exception.
I think class_alias should be able to handle the leading backslashes or return
bool(false) if it can't.
[2012-04-18 06:11:21] ahar...@php.net
Description:
Aliasing namespaced classes currently expects that class names will be given in
the same form as the ZE uses internally; ie without a leading backslash. Since
that's inconsistent with the absolute form in PHP, it would be good if
class_alias() could also ignore a leading backslash.
Test script:
---
foo();
Expected result:
42
Actual result:
--
Fatal error: Class 'B\C' not found in /private/tmp/test.php on line 7
--
Edit this bug report at https://bugs.php.net/bug.php?id=61759&edit=1
Req #61759 [PATCH]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759&edit=1
ID: 61759
Patch added by: jpa...@php.net
Reported by:ahar...@php.net
Summary:class_alias() should accept classes with leading
backslashes
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Irrelevant
PHP Version:master-Git-2012-04-18 (Git)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: fix-class_alias
Revision: 1377596813
URL:
https://bugs.php.net/patch-display.php?bug=61759&patch=fix-class_alias&revision=1377596813
Previous Comments:
[2013-08-27 09:45:12] jpa...@php.net
Johannes: I agree, but we could start by patching this bug report right?
I got a patch here : https://github.com/jpauli/php-
src/compare/class_alias_registration_fix
[2013-08-26 18:32:26] johan...@php.net
Note: The bug report is too restrictive. A proper patch would have to work on
all places where classnames come from string context. This at first means
verifying that all places go via zend_lookup_class() and related functions, not
EG(class_table) / CG(class_table)
[2013-08-26 18:13:08] contact at jubianchi dot fr
I experienced the exact same issue on PHP 5.4.17 on OS X 10.9 (Mavericks DP6).
I wrote a simple test case, here it is :
Test script:
---
namespace jubianchi\Alias {
class A {}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'C'));
$reflector = new \ReflectionClass('C');
var_dump($reflector->getName());
var_dump(class_alias('\\jubianchi\\Alias\\A', '\\jubianchi\\Alias\\B'));
try {
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector->getName());
} catch(\Exception $e) {
var_dump(get_class($e) . ': ' . $e->getMessage());
}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'jubianchi\\Alias\\B'));
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector->getName());
}
Expected result:
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(17) "jubianchi\Alias\A"
Or:
bool(true)
string(17) "jubianchi\Alias\A"
bool(false)
string(60) "ReflectionException: Class \jubianchi\Alias\B does not exist"
bool(true)
string(17) "jubianchi\Alias\A"
Actual result:
bool(true)
string(1) "A"
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(60) "ReflectionException: Class \jubianchi\Alias\B does not exist"
bool(true)
string(17) "jubianchi\Alias\A"
As you can see, class_alias returns bool(true) as if everything went fine, so
we
expect the alias to be available but a reflection on the latter throws an
exception.
I think class_alias should be able to handle the leading backslashes or return
bool(false) if it can't.
[2012-04-18 06:11:21] ahar...@php.net
Description:
Aliasing namespaced classes currently expects that class names will be given in
the same form as the ZE uses internally; ie without a leading backslash. Since
that's inconsistent with the absolute form in PHP, it would be good if
class_alias() could also ignore a leading backslash.
Test script:
---
foo();
Expected result:
42
Actual result:
--
Fatal error: Class 'B\C' not found in /private/tmp/test.php on line 7
--
Edit this bug report at https://bugs.php.net/bug.php?id=61759&edit=1
Req #61759 [Com]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759&edit=1 ID: 61759 Comment by: jpa...@php.net Reported by:ahar...@php.net Summary:class_alias() should accept classes with leading backslashes Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Irrelevant PHP Version:master-Git-2012-04-18 (Git) Block user comment: N Private report: N New Comment: Yep, let's start finding all places where classes as strings can be used, and patch them all to use zend_lookup_class(). There shouldn't be tons of them AFAIR. Previous Comments: [2013-08-27 10:19:53] contact at jubianchi dot fr I agree with Johannes about consistency. The severity is not really is not very high and this use case can easily be handled at a useland level. As long as this behavior is not "fixed" I think a warning on the doc shoudl be enough, even if I'd like to see it fixed (but as I said, it's not a big deal at the moment). BTW, thanks for you work Julien :) [2013-08-27 10:08:00] johan...@php.net Technically we could, but it adds some inconsistency if one place allows this but others not and that should be avoided. ---- [2013-08-27 09:46:53] jpa...@php.net The following patch has been added/updated: Patch Name: fix-class_alias Revision: 1377596813 URL: https://bugs.php.net/patch-display.php?bug=61759&patch=fix-class_alias&revision=1377596813 -------- [2013-08-27 09:45:12] jpa...@php.net Johannes: I agree, but we could start by patching this bug report right? I got a patch here : https://github.com/jpauli/php- src/compare/class_alias_registration_fix [2013-08-26 18:32:26] johan...@php.net Note: The bug report is too restrictive. A proper patch would have to work on all places where classnames come from string context. This at first means verifying that all places go via zend_lookup_class() and related functions, not EG(class_table) / CG(class_table) 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=61759 -- Edit this bug report at https://bugs.php.net/bug.php?id=61759&edit=1
Bug #65665 [Com]: Exception not properly caught when opcache enabled
Edit report at https://bugs.php.net/bug.php?id=65665&edit=1 ID: 65665 Comment by: jpa...@php.net Reported by:ryan dot brothers at gmail dot com Summary:Exception not properly caught when opcache enabled Status: Open Type: Bug Package:opcache Operating System: Linux PHP Version:5.5.3 Block user comment: N Private report: N New Comment: This is an optimizer bug. If you run with opcache.optimization_level=0 , the bug disappears. I guess the bug is in the optimizer pass that handles ZEND_CATCH. PS : I reproduced with a 5.4 base. Previous Comments: [2013-09-13 00:15:06] ryan dot brothers at gmail dot com Description: When running the following script with opcache enabled, the exception is not caught by the correct catch block. The exception should be caught by the 'caught by 1' block, but it is instead caught by the 'caught by 2' block. Disabling opcache causes the exception to be caught in the correct block. Run the script with: php -n -d zend_extension=opcache.so -d opcache.enable_cli=1 script.php Test script: --- https://bugs.php.net/bug.php?id=65665&edit=1
[PHP-BUG] Req #60573 [NEW]: type hinting with "self" keyword causes weird errors
From:
Operating system: *nix
PHP version: 5.3.8
Package: Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:type hinting with "self" keyword causes weird errors
Description:
"self" should be thought as "the class where the keyword is written in".
Here is then a strange behavior using inheritance :
Test script:
---
class Foo {
public function setSelf(self $s) { }
}
class Bar extends Foo {
public function setSelf(self $s) { }
}
Expected result:
Strict Standards as Bar::setself() signature doesn't respect Foo::setSelf()
signature.
Foo's one has a type hint on Foo (using self keyword), but Bar's one on Bar
(still using self keyword) : the methods then have a signature mismatch,
and PHP
should complain about that
Actual result:
--
Nothing happens.
Trying this gives the correct E_STRICT error, correct behavior :
class Foo {
public function setSelf(Foo $s) { }
}
class Bar extends Foo {
public function setSelf(Bar $s) { }
}
--
Edit bug report at https://bugs.php.net/bug.php?id=60573&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60573&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60573&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60573&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60573&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60573&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60573&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60573&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60573&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60573&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60573&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60573&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60573&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60573&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60573&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60573&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60573&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60573&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60573&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60573&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60573&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60573&r=mysqlcfg
[PHP-BUG] Bug #61025 [NEW]: __invoke() visibility not honored
From: Operating system: *nix PHP version: 5.3.10 Package: Class/Object related Bug Type: Bug Bug description:__invoke() visibility not honored Description: __invoke() visibility is not honored when indirectly called as $obj(). It is, when directly called, via $obj->__invoke(); Please, note as well that declaring __invoke() as static works as well, I think it shouldn't (nonsense) Test script: --- __invoke(); */ Expected result: Call to private method Bar::__invoke() from context ... Actual result: -- Bar -- Edit bug report at https://bugs.php.net/bug.php?id=61025&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61025&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61025&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61025&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61025&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61025&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61025&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61025&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61025&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61025&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61025&r=support Expected behavior: https://bugs.php.net/fix.php?id=61025&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61025&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61025&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61025&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61025&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61025&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61025&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61025&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61025&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61025&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61025&r=mysqlcfg
[PHP-BUG] Bug #61837 [NEW]: Problem collecting stats with mysqlnd
From: jpauli
Operating system: Linux
PHP version: 5.3.10
Package: MySQL related
Bug Type: Bug
Bug description:Problem collecting stats with mysqlnd
Description:
mysqli_get_connection_stats() doesn't seem to work, but
mysqli_get_client_stats()
does.
mysqli_get_connection_stats() gives nearly no information at all, big part
of
fields it returns are '0' valued
Test script:
---
ini_set('mysqlnd.collect_statistics', 1);
ini_set('mysqlnd.collect_memory_statistics', 1);
$db = mysqli_connect('server', 'user', 'secret', 'mydb');
$result = mysqli_query($db,"SELECT user_id FROM users LIMIT 5");
mysqli_data_seek($result, 5);
$data = mysqli_fetch_row($result);
var_dump(mysqli_get_connection_stats($db));
Expected result:
I expect the keys "mem_***" to contain non null values
"rows_fetched_from_client_normal_buffered" should be 1 as I fetch one value
from
a buffered non prepared dataset
Actual result:
--
array(160) {
["bytes_sent"]=>
string(3) "193"
["bytes_received"]=>
string(3) "379"
["packets_sent"]=>
string(1) "4"
["packets_received"]=>
string(2) "12"
["protocol_overhead_in"]=>
string(2) "48"
["protocol_overhead_out"]=>
string(2) "16"
["bytes_received_ok_packet"]=>
string(2) "11"
["bytes_received_eof_packet"]=>
string(1) "9"
["bytes_received_rset_header_packet"]=>
string(1) "5"
["bytes_received_rset_field_meta_packet"]=>
string(3) "202"
["bytes_received_rset_row_packet"]=>
string(2) "66"
["bytes_received_prepare_response_packet"]=>
string(1) "0"
["bytes_received_change_user_packet"]=>
string(1) "0"
["packets_sent_command"]=>
string(1) "1"
["packets_received_ok"]=>
string(1) "1"
["packets_received_eof"]=>
string(1) "1"
["packets_received_rset_header"]=>
string(1) "1"
["packets_received_rset_field_meta"]=>
string(1) "2"
["packets_received_rset_row"]=>
string(1) "6"
["packets_received_prepare_response"]=>
string(1) "0"
["packets_received_change_user"]=>
string(1) "0"
["result_set_queries"]=>
string(1) "1"
["non_result_set_queries"]=>
string(1) "0"
["no_index_used"]=>
string(1) "0"
["bad_index_used"]=>
string(1) "0"
["slow_queries"]=>
string(1) "0"
["buffered_sets"]=>
string(1) "1"
["unbuffered_sets"]=>
string(1) "0"
["ps_buffered_sets"]=>
string(1) "0"
["ps_unbuffered_sets"]=>
string(1) "0"
["flushed_normal_sets"]=>
string(1) "0"
["flushed_ps_sets"]=>
string(1) "0"
["ps_prepared_never_executed"]=>
string(1) "0"
["ps_prepared_once_executed"]=>
string(1) "0"
["rows_fetched_from_server_normal"]=>
string(1) "5"
["rows_fetched_from_server_ps"]=>
string(1) "0"
["rows_buffered_from_client_normal"]=>
string(1) "5"
["rows_buffered_from_client_ps"]=>
string(1) "0"
["rows_fetched_from_client_normal_buffered"]=>
string(1) "0"
["rows_fetched_from_client_normal_unbuffered"]=>
string(1) "0"
["rows_fetched_from_client_ps_buffered"]=>
string(1) "0"
["rows_fetched_from_client_ps_unbuffered"]=>
string(1) "0"
["rows_fetched_from_client_ps_cursor"]=>
string(1) "0"
["rows_affected_normal"]=>
string(1) "0"
["rows_affected_ps"]=>
string(1) "0"
["rows_skipped_normal"]=>
string(1) "5"
["rows_skipped_ps"]=>
string(1) "0"
["copy_on_write_saved"]=>
string(1) "0"
["copy_on_write_performed"]=>
string(1) "0"
["command_buffer_too_small"]=>
string(1) "0"
["connect_success"]=>
string(1) "1"
["connect_failure"]=>
string(1) "0"
["connection_reused"]=>
string(1) "0"
["reconnect"]=>
string(1) "0"
["pconnect_success"]=>
string(1) "0"
["active_connections"]=>
string(1) "1"
["active_persistent_connections"]=>
string(1) "0"
["explicit_close"]=>
string(1) "0"
["implicit_close"]=>
string(1) "0"
["disconnect_close"]=>
string(1) "0"
["in_middle_of_command_close"]=>
string(1) "0"
["explicit_free_result"]=>
string(1) "0"
["implicit_free_result"]=>
string(1) "0"
["explicit_stmt_close"]=>
string(1) "0"
["implicit_stmt_close"]=>
string(1) "0"
["mem_emalloc_count"]=>
string(1) "0"
["mem_emalloc_amount"]=>
string(1) "0"
["mem_ecalloc_count"]=>
string(1) "0"
["mem_ecalloc_amount"]=>
string(1) "0"
["mem_erealloc_count"]=>
string(1) "0"
["mem_erealloc_amount"]=>
string(1) "0"
["mem_efree_count"]=>
string(1) "0"
["mem_efree_amount"]=>
string(1) "0"
["mem_malloc_count"]=>
string(1) "0"
["mem_malloc_amount"]=>
string(1) "0"
["mem_calloc_count"]=>
string(1) "0"
["mem_calloc_amount"]=>
string(1) "0"
["mem_realloc_count"]=>
string(1) "0"
["mem_realloc_amount"]=>
string(1) "0"
["mem_free_count"]=>
string(1) "0"
["mem_free_amount"]=>
string(1) "0"
["mem_estrndup_count"]=>
string(1) "0"
["mem_strndup_count"]=>
string(1) "0"
["mem_estndup_count"]=>
string(1) "0"
["mem_strdup_count"]=>
string(1) "0"
["proto_text_fetched_null"]=>
string(1) "0"
["proto_
[PHP-BUG] Bug #61838 [NEW]: mysqli_get_cache_stats() does nothing
From: jpauli Operating system: Linux PHP version: 5.3.10 Package: MySQL related Bug Type: Bug Bug description:mysqli_get_cache_stats() does nothing Description: mysqli_get_cache_stats() just return an empty array, always. It has not been implemented, but it's documented :) Test script: --- See source code of mysqli_get_cache_stats(), it always returns an empty array, whatever happens Expected result: mysqli_get_cache_stats() returns useful data Actual result: -- mysqli_get_cache_stats() is useless actually -- Edit bug report at https://bugs.php.net/bug.php?id=61838&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61838&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61838&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61838&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61838&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61838&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61838&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61838&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61838&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61838&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61838&r=support Expected behavior: https://bugs.php.net/fix.php?id=61838&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61838&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61838&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61838&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61838&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61838&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61838&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61838&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61838&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61838&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61838&r=mysqlcfg
[PHP-BUG] Bug #52098 [NEW]: Own PDOStatement implementation ignore __call()
From:
Operating system: *nix & Win
PHP version: 5.3.2
Package: PDO related
Bug Type: Bug
Bug description:Own PDOStatement implementation ignore __call()
Description:
When using an own PDOStatement implementation, __call() is simply ignored
in it.
*Additionally* it may lead to segfaults if the Statement object is user
constructed.
The problem is in pdo_stmt.c _zend_function *dbstmt_method_get(){ :
if (zend_hash_find(&Z_OBJCE_P(object)->function_table, lc_method_name,
method_len+1, (void**)&fbc) == FAILURE) {
pdo_stmt_t *stmt = (pdo_stmt_t*)zend_object_store_get_object(object
TSRMLS_CC);
if (!stmt->dbh->cls_methods[PDO_DBH_DRIVER_METHOD_KIND_STMT]) {
[...]
stmt is not initialized properly when it comes back from the object store.
I didn't search deeper from that point.
The bug has already been reported and marked as fixed (46396), but it
doesn't seem to have been fixed.
Test script:
---
setAttribute(PDO::ATTR_STATEMENT_CLASS, array('MyStatement'));
$r = $p->query('SELECT 123');
echo $r->foo(); // (1)
$obj = new MyStatement;
echo $obj->foo(); // (2)
Expected result:
foo called (1)
foo called (2)
Actual result:
--
Fatal error: Call to undefined method MyStatement::foo() in (1)
Segmentation Fault (2)
--
Edit bug report at http://bugs.php.net/bug.php?id=52098&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52098&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52098&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52098&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52098&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52098&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52098&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52098&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52098&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52098&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52098&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52098&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52098&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52098&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52098&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52098&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52098&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52098&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52098&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52098&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52098&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52098&r=mysqlcfg
Bug #52098 [Ana]: Own PDOStatement implementation ignore __call()
Edit report at http://bugs.php.net/bug.php?id=52098&edit=1
ID: 52098
User updated by: jpa...@php.net
Reported by: jpa...@php.net
Summary:Own PDOStatement implementation ignore __call()
Status: Analyzed
Type: Bug
Package:PDO related
Operating System: *nix & Win
PHP Version:5.3.2
Block user comment: N
New Comment:
Has the patch been merged to 5.3.3 ?
I'm still experiencing the bug on 5.3.3, please think about merging it
to the right branch for the next release.
Test would be great as well, I can manage that if you want.
Previous Comments:
[2010-06-17 01:33:02] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=300504
Log: - New tests related to #52098
[2010-06-17 01:29:39] fel...@php.net
I've committed a fix for the crash:
http://svn.php.net/viewvc?view=revision&revision=300503
[2010-06-17 01:09:56] fel...@php.net
I can reproduce it with another test case:
foo());
Adding the support to __call lead to a strange behavior for classes that
inherits PDOStatement. As it must be check if the called method is a
user method or an driver method (which isn't stored in function_table) -
that's when the instance is created by PDO object.
If we introduce __call check, it must be done after the driver method
checking... which will behave diferently when the instance is created by
PDO or not...
[2010-06-17 00:20:50] fel...@php.net
I cannot reproduce the segmentation fault.
--------
[2010-06-16 17:12:27] jpa...@php.net
Description:
When using an own PDOStatement implementation, __call() is simply
ignored in it.
*Additionally* it may lead to segfaults if the Statement object is user
constructed.
The problem is in pdo_stmt.c _zend_function *dbstmt_method_get(){ :
if (zend_hash_find(&Z_OBJCE_P(object)->function_table, lc_method_name,
method_len+1, (void**)&fbc) == FAILURE) {
pdo_stmt_t *stmt = (pdo_stmt_t*)zend_object_store_get_object(object
TSRMLS_CC);
if (!stmt->dbh->cls_methods[PDO_DBH_DRIVER_METHOD_KIND_STMT]) {
[...]
stmt is not initialized properly when it comes back from the object
store.
I didn't search deeper from that point.
The bug has already been reported and marked as fixed (46396), but it
doesn't seem to have been fixed.
Test script:
---
setAttribute(PDO::ATTR_STATEMENT_CLASS, array('MyStatement'));
$r = $p->query('SELECT 123');
echo $r->foo(); // (1)
$obj = new MyStatement;
echo $obj->foo(); // (2)
Expected result:
foo called (1)
foo called (2)
Actual result:
--
Fatal error: Call to undefined method MyStatement::foo() in (1)
Segmentation Fault (2)
--
Edit this bug report at http://bugs.php.net/bug.php?id=52098&edit=1
[PHP-BUG] Bug #53405 [NEW]: accessing the iterator inside a foreach loop leads to strange results
From:
Operating system: *nix
PHP version: 5.3.3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:accessing the iterator inside a foreach loop leads to strange
results
Description:
foreach() is supposed to work on a copy of the iternal iterator.
However, manipulating the iterator inside the foreach loop leads to very
strange results.
-> Also try to print the result of current() inside the foreach loop in the
3 use cases provided. You'll see that the iterator is some kind of
manipulated by foreach
Test script:
---
$a = range('a','d');
foreach ($a as $v) { }
var_dump(current($a));
$a = range('a','d');
foreach ($a as $v) { current($a); }
var_dump(current($a));
$a = range('a','d');
foreach ($a as &$v) { current($a); }
var_dump(current($a));
Expected result:
'a'
'a'
'a'
Actual result:
--
false
'b'
false
--
Edit bug report at http://bugs.php.net/bug.php?id=53405&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53405&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53405&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53405&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53405&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53405&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53405&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53405&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53405&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53405&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53405&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53405&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53405&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53405&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53405&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53405&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53405&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53405&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53405&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53405&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53405&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53405&r=mysqlcfg
[PHP-BUG] Req #54069 [NEW]: Improve parser about affecting a closure by reference
From:
Operating system: *nix
PHP version: 5.3.5
Package: Unknown/Other Function
Bug Type: Feature/Change Request
Bug description:Improve parser about affecting a closure by reference
Description:
When affecting a closure by reference, the parser doesn't recognize the
pattern and issues a parse error.
It could be better to explicitly notice the error
Test script:
---
$a = &function () { };
Expected result:
Some kind of "Warning, Closure cannot be assigned by reference"
Actual result:
--
Parse error: syntax error, unexpected T_FUNCTION
--
Edit bug report at http://bugs.php.net/bug.php?id=54069&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54069&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54069&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54069&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54069&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54069&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54069&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54069&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54069&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54069&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54069&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54069&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54069&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54069&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54069&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54069&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54069&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54069&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54069&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54069&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54069&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54069&r=mysqlcfg
[PHP-BUG] Bug #54367 [NEW]: Use of closure causes problem in ArrayAccess
From:
Operating system: *nix
PHP version: 5.3.6
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Use of closure causes problem in ArrayAccess
Description:
Closures cant use variables from external context when the context is in
ArrayAccess method
Test script:
---
%s', $offset, $var);
};
}
}
$a = new MyObjet();
echo $a['p']('foo');
Expected result:
foo
Actual result:
--
PHP Notice: Undefined variable: offset in {file.php} on line 11
--
Edit bug report at http://bugs.php.net/bug.php?id=54367&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54367&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54367&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54367&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54367&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54367&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54367&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54367&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54367&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54367&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54367&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54367&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54367&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54367&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54367&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54367&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54367&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54367&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54367&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54367&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54367&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54367&r=mysqlcfg
Bug #54367 [Asn]: Use of closure causes problem in ArrayAccess
Edit report at http://bugs.php.net/bug.php?id=54367&edit=1
ID: 54367
User updated by: jpa...@php.net
Reported by: jpa...@php.net
Summary:Use of closure causes problem in ArrayAccess
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: *nix
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Felipe: strange, I got no crash with your code (5.3.6,Linux,
self-compiled)
Previous Comments:
[2011-03-24 22:49:49] fel...@php.net
I can reproduce a crash with:
Breakpoint 1, 0x085368b3 in ZEND_SEND_VAL_SPEC_CONST_HANDLER
(execute_data=0x8ade614, tsrm_ls=0x89022a0)
at /home/felipe/dev/php5/Zend/zend_vm_execute.h:1719
1719&& ARG_MUST_BE_SENT_BY_REF(EX(fbc),
opline->op2.u.opline_num)) {
(gdb) p execute_data->fbc->common
$7 = {type = 90 'Z', function_name = 0x5a5a5a5a , scope = 0x5a5a5a5a, fn_flags = 1515870810,
prototype = 0x5a5a5a5a, num_args = 1515870810, required_num_args =
1515870810, arg_info = 0x5a5a5a5a, pass_rest_by_reference = 90 'Z',
return_reference = 90 'Z'}
--------
[2011-03-24 13:52:23] jpa...@php.net
Description:
Closures cant use variables from external context when the context is in
ArrayAccess method
Test script:
---
%s', $offset, $var);
};
}
}
$a = new MyObjet();
echo $a['p']('foo');
Expected result:
foo
Actual result:
--
PHP Notice: Undefined variable: offset in {file.php} on line 11
--
Edit this bug report at http://bugs.php.net/bug.php?id=54367&edit=1
[PHP-BUG] Bug #54440 [NEW]: stream_context_set_default() should publish the default context to everybody
From:
Operating system: *nix
PHP version: 5.3.6
Package: Streams related
Bug Type: Bug
Bug description:stream_context_set_default() should publish the default context
to everybody
Description:
stream_context_set_default() doesn't publish the context to all PHP
extension.
Example is ext/libxml that doesn't recognize the context.
Test script:
---
stream_context_set_default(array('http'=>array('proxy'=>'my_proxy_url')));
$x = simplexml_load_file('http://some_resource');
Expected result:
The resource gets loaded through the HTTP proxy
Actual result:
--
The resource is not loaded through the HTTP proxy.
For this to work, we have to use :
$ctx =
stream_context_create(array('http'=>array('proxy'=>'my_proxy_url')));
libxml_set_streams_context($ctx); // userland manual bind
$x = simplexml_load_file('http://some_resource');
--
Edit bug report at http://bugs.php.net/bug.php?id=54440&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54440&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54440&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54440&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54440&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54440&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54440&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54440&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54440&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54440&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54440&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54440&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54440&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54440&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54440&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54440&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54440&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54440&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54440&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54440&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54440&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54440&r=mysqlcfg
Bug #54440 [Opn]: stream_context_set_default() should publish the default context to everybody
Edit report at http://bugs.php.net/bug.php?id=54440&edit=1
ID: 54440
User updated by: jpa...@php.net
Reported by: jpa...@php.net
Summary:stream_context_set_default() should publish the
default context to everybody
Status: Open
Type: Bug
Package:Streams related
Operating System: *nix
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
See also #52926
Previous Comments:
[2011-04-01 11:43:32] jpa...@php.net
Description:
stream_context_set_default() doesn't publish the context to all PHP
extension.
Example is ext/libxml that doesn't recognize the context.
Test script:
---
stream_context_set_default(array('http'=>array('proxy'=>'my_proxy_url')));
$x = simplexml_load_file('http://some_resource');
Expected result:
The resource gets loaded through the HTTP proxy
Actual result:
--
The resource is not loaded through the HTTP proxy.
For this to work, we have to use :
$ctx =
stream_context_create(array('http'=>array('proxy'=>'my_proxy_url')));
libxml_set_streams_context($ctx); // userland manual bind
$x = simplexml_load_file('http://some_resource');
--
Edit this bug report at http://bugs.php.net/bug.php?id=54440&edit=1
