php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #52098 Own PDOStatement implementation ignore __call()
Submitted: 2010-06-16 17:12 UTC Modified: 2014-01-01 12:48 UTC
Votes:6
Avg. Score:3.0 ± 1.2
Reproduced:4 of 4 (100.0%)
Same Version:2 (50.0%)
Same OS:3 (75.0%)
From: jpauli@php.net Assigned:
Status: Closed Package: PDO Core
PHP Version: 5.3.2 OS: *nix & Win
Private report: No CVE-ID:
 [2010-06-16 17:12 UTC] 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)

Patches

Add a Patch

Pull Requests

Pull requests:

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-06-17 00:20 UTC] felipe@php.net
I cannot reproduce the segmentation fault.
 [2010-06-17 01:09 UTC] 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 01:29 UTC] felipe@php.net
I've committed a fix for the crash:
http://svn.php.net/viewvc?view=revision&revision=300503
 [2010-06-17 01:33 UTC] felipe@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=300504
Log: - New tests related to #52098
 [2010-06-17 02:16 UTC] felipe@php.net
-Status: Open +Status: Analyzed
 [2010-09-30 17:58 UTC] jpauli@php.net
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.
 [2010-10-02 03:21 UTC] felipe@php.net
I just fixed the SIGSEGV.
 [2014-01-01 12:48 UTC] felipe@php.net
-Package: PDO related +Package: PDO Core
 [2016-03-21 14:52 UTC] jpauli@php.net
Automatic comment on behalf of jpauli
Revision: http://git.php.net/?p=php-src.git;a=commit;h=d3d64b7c62cb7b63d854b1cbc6a032c4995cdba8
Log: Reworked Fix bug #52098
 [2016-03-21 14:52 UTC] jpauli@php.net
-Status: Analyzed +Status: Closed
 [2016-03-21 14:52 UTC] jpauli@php.net
Automatic comment on behalf of daniel.persson@textalk.se
Revision: http://git.php.net/?p=php-src.git;a=commit;h=e541cd8e6bcf5a80b85379afa35e54a82c74bde2
Log: Fix bug #52098
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Sun Feb 26 21:01:35 2017 UTC