php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #38166 Calling PDO::prepare or PDO::query then calling non-existent method crashes PHP
Submitted: 2006-07-20 17:41 UTC Modified: 2006-07-24 16:07 UTC
From: jerome at macsaresexy dot com Assigned:
Status: Not a bug Package: PDO related
PHP Version: 5.1.4 OS: Ubuntu Linux
Private report: No CVE-ID: None
View Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
29 - 12 = ?
Subscribe to this entry?

 
 [2006-07-20 17:41 UTC] jerome at macsaresexy dot com 
Description:
------------
PHP crashes with a seg fault if you try to call a method that 
doesn't exist, on any particular object, after a call from 
PDO::prepare() or PDO::query().

Reproduce code:
---------------
class TestClass {
    static $db;

    function test() {
        $stmt = self::$db->prepare('SELECT * FROM users');
        $this->omg();
    }
}
TestClass::$db = new PDO('mysql:host=localhost;dbname=mydb','root','');
$test = new TestClass();
$test->test();

Expected result:
----------------
Should produce a call to undefined method TestClass::omg() 
fatal error message.

Actual result:
--------------
What I get instead is a segmentation fault of the child apache 
process seen in the error_log file.  This only happens when 
$db->prepare() is assigned to a variable too, if $stmt = isn't 
there, it won't crash.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-07-23 07:21 UTC] tony2001@php.net 
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Can't reproduce.
 [2006-07-24 15:39 UTC] jerome at macsaresexy dot com 
This is from within my application, seems I actually 
couldn't crash it with the simplified case I posted, but 
will if I use that simple class test from within my 
application (which loads many things in a common file 
including the PDO connection)
This is the backtrace when it happens:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1215007040 (LWP 19351)]
0xb73e60c6 in mysql_more_results ()
   from /usr/local/lib/mysql/libmysqlclient.so.15
(gdb) bt
#0  0xb73e60c6 in mysql_more_results ()
   from /usr/local/lib/mysql/libmysqlclient.so.15
#1  0xb759fd23 in pdo_mysql_stmt_dtor (stmt=0x83d499c)
    at /home/jerome/Source/php-5.1.4/ext/pdo_mysql/
mysql_statement.c:71
#2  0xb76f4b63 in free_statement (stmt=0x83d499c)
    at /home/jerome/Source/php-5.1.4/ext/pdo/pdo_stmt.c:2200
#3  0xb781041b in zend_objects_store_free_object_storage 
(objects=0xb794688c)
    at /home/jerome/Source/php-5.1.4/Zend/
zend_objects_API.c:86
#4  0xb77e7411 in shutdown_executor ()
    at /home/jerome/Source/php-5.1.4/Zend/
zend_execute_API.c:281
#5  0xb77f4205 in zend_deactivate ()
    at /home/jerome/Source/php-5.1.4/Zend/zend.c:854
#6  0xb77b1de9 in php_request_shutdown (dummy=0x0)
    at /home/jerome/Source/php-5.1.4/main/main.c:1287
#7  0xb7892d77 in php_handler (r=0x824cf50)
    at /home/jerome/Source/php-5.1.4/sapi/apache2handler/
sapi_apache2.c:445
#8  0x08077e38 in ap_run_handler ()
#9  0x080781bc in ap_invoke_handler ()
#10 0x08069c7f in ap_process_request ()
#11 0x08064c52 in _start ()
 [2006-07-24 16:07 UTC] tony2001@php.net 
Duplicate of bug #37445.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 24 00:00:02 2025 UTC