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: jpauli@php.net
Reported by: jpauli@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] felipe@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] felipe@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] felipe@php.net
I can reproduce it with another test case:
<?php
class MyStatement extends PDOStatement
{
}
$obj = new MyStatement;
var_dump($obj->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] felipe@php.net
I cannot reproduce the segmentation fault.
------------------------------------------------------------------------
[2010-06-16 17:12:27] jpauli@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:
---------------
<?php
class MyStatement extends PDOStatement
{
public function __call($meth, $args)
{
return "$meth called";
}
}
$p = new PDO('sqlite::memory:');
$p->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 XXXX (1)
Segmentation Fault (2)
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=52098&edit=1
Thread (8 messages)