php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #56965 Segfault in destructor of pdo_statement for mysql
Submitted: 2006-04-20 10:20 UTC Modified: 2008-05-08 10:57 UTC
From: harmann at mayflower dot de Assigned:
Status: Duplicate Package: PDO_MYSQL (PECL)
PHP Version: 5_1 CVS-2006-05-18 OS: linux-2.6.10/32
Private report: No CVE-ID: None
 [2006-04-20 10:20 UTC] harmann at mayflower dot de
Description:
------------
Using PHP_5_1 from today i got a segfault at the end of the request due to pdo_mysql.
Backtrace: 
#0  0xb7b1b927 in mysql_more_results () from /usr/lib/libmysqlclient.so.14
#1  0x08124419 in free_statement (stmt=0x864e2ac) at /home/src/php5/ext/pdo/pdo_stmt.c:2200
#2  0x08292549 in zend_objects_store_free_object_storage (objects=0x83e569c) at /home/src/php5/Zend/zend_objects_API.c:86
#3  0x0827082f in shutdown_executor () at /home/src/php5/Zend/zend_execute_API.c:281
#4  0x0827b274 in zend_deactivate () at /home/src/php5/Zend/zend.c:854
#5  0x08241cd6 in php_request_shutdown (dummy=0x0) at /home/src/php5/main/main.c:1287
#6  0x082e5000 in main (argc=1, argv=0xbffffea4) at /home/src/php5/sapi/cgi/cgi_main.c:1624


The reason is line 71 of ext/pdo_mysql/mysql_statement.c, where "while (mysql_more_results(S->H->server))" is done with server being 0x0. 
Adding a simple 
if (S->H->server) while ... 
did help in my case. 
Best regards, 
johann  


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-04-29 22:40 UTC] wez@php.net
I believe that I've already fixed this in CVS.
The current snapshots have that fix.
 [2006-05-03 02:03 UTC] harmann at mayflower dot de
Hmm, i still get the same segfault with the current PHP_5_1.
 [2006-05-12 10:51 UTC] indeyets at gmail dot com
I got the following with PHP 5.1.4 (freebsd port)

#0  0x2908180a in mysql_more_results () from /usr/local/lib/mysql/libmysqlclient.so.15
#1  0x29064c4c in pdo_mysql_stmt_dtor (stmt=0x8743124) at /usr/ports/lang/php5/work/php-5.1.4/ext/pdo_mysql/mysql_statement.c:79
#2  0x29022bee in free_statement (stmt=0x8743124) at /usr/ports/lang/php5/work/php-5.1.4/ext/pdo/pdo_stmt.c:2200
#3  0x29022c63 in pdo_dbstmt_free_storage (stmt=0x8743124) at /usr/ports/lang/php5/work/php-5.1.4/ext/pdo/pdo_stmt.c:2245
#4  0x28740a46 in ?? () from /usr/local/libexec/apache22/libphp5.so
 [2006-05-12 11:51 UTC] indeyets at gmail dot com
reverting this patch solves the problem for me http://cvs.php.net/viewcvs.cgi/php-src/ext/pdo_mysql/mysql_statement.c?r1=1.48.2.12&r2=1.48.2.13
 [2006-05-18 04:56 UTC] schlueter at phpbar dot de
The problem still exists in current 5_1 CVS.
 [2006-06-14 10:50 UTC] ludicruz at yahoo dot com
I'm having the same problem with 5.1.4 on windows server 2003.
the script exits with code 0xc0000005

thanks, 
Jordan
 [2006-06-22 05:55 UTC] shadow3d at o2 dot pl
Latest php5.2.0-dev form snaps on linux the same.
And not on the first query.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1704789072 (LWP 25318)]
0xa7260507 in mysql_more_results () from /usr/lib/libmysqlclient_r.so.15
(gdb) bt
#0  0xa7260507 in mysql_more_results () from /usr/lib/libmysqlclient_r.so.15
#1  0xa7638533 in free_statement (stmt=0xa79029a0, tsrm_ls=0x82e2280) at /home/tomek/src/php5.2/ext/pdo/pdo_stmt.c:2225
#2  0xa7823136 in zend_objects_store_free_object_storage (objects=0x8327268, tsrm_ls=0x82e2280) at /home/tomek/src/php5.2/Zend/zend_objects_API.c:86
#3  0xa77f541f in shutdown_executor (tsrm_ls=0x82e2280) at /home/tomek/src/php5.2/Zend/zend_execute_API.c:281
#4  0xa78025f5 in zend_deactivate (tsrm_ls=0x82e2280) at /home/tomek/src/php5.2/Zend/zend.c:854
#5  0xa77b5c3e in php_request_shutdown (dummy=0x0) at /home/tomek/src/php5.2/main/main.c:1300
#6  0xa7895d54 in php_handler (r=0x82de2c0) at /home/tomek/src/php5.2/sapi/apache2handler/sapi_apache2.c:452
#7  0x0807af75 in ap_run_handler ()
#8  0x0807b3b1 in ap_invoke_handler ()
#9  0x0806a638 in ap_process_request ()
#10 0x080652f8 in _start ()
 [2006-08-06 14:16 UTC] i-am at wykis dot com
Problem persisting here.

Simple query and then looping: while ($row=$resource->fetch()) gives the alike error.
This is at the end of request for me.

Detailed valgrind report:
==2248== Invalid read of size 4
==2248==    at 0x817D533: (within /usr/lib/php5/bin/php)
==2248==    by 0x817A480: (within /usr/lib/php5/bin/php)
==2248==    by 0x82D6995: zend_objects_store_free_object_storage (in /usr/lib/php5/bin/php)
==2248==    by 0x82B6943: shutdown_executor (in /usr/lib/php5/bin/php)
==2248==    by 0x82C0A2A: zend_deactivate (in /usr/lib/php5/bin/php)
==2248==    by 0x8288BD0: php_request_shutdown (in /usr/lib/php5/bin/php)
==2248==    by 0x8328D9F: main (in /usr/lib/php5/bin/php)
==2248==  Address 0x4C91FAC is 12 bytes inside a block of size 44 free'd
==2248==    at 0x401C0C3: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==2248==    by 0x82ACCB0: _efree (in /usr/lib/php5/bin/php)
==2248==    by 0x817C740: (within /usr/lib/php5/bin/php)
==2248==    by 0x81766D9: (within /usr/lib/php5/bin/php)
==2248==    by 0x82D6995: zend_objects_store_free_object_storage (in /usr/lib/php5/bin/php)
==2248==    by 0x82B6943: shutdown_executor (in /usr/lib/php5/bin/php)
==2248==    by 0x82C0A2A: zend_deactivate (in /usr/lib/php5/bin/php)
==2248==    by 0x8288BD0: php_request_shutdown (in /usr/lib/php5/bin/php)
==2248==    by 0x8328D9F: main (in /usr/lib/php5/bin/php)
==2248==
==2248== Invalid read of size 4
==2248==    at 0x45AD7C1: mysql_more_results (in /usr/lib/libmysqlclient.so.14.0.0)
==2248==    by 0x817A480: (within /usr/lib/php5/bin/php)
==2248==    by 0x82D6995: zend_objects_store_free_object_storage (in /usr/lib/php5/bin/php)
==2248==    by 0x82B6943: shutdown_executor (in /usr/lib/php5/bin/php)
==2248==    by 0x82C0A2A: zend_deactivate (in /usr/lib/php5/bin/php)
==2248==    by 0x8288BD0: php_request_shutdown (in /usr/lib/php5/bin/php)
==2248==    by 0x8328D9F: main (in /usr/lib/php5/bin/php)
==2248==  Address 0x3A4 is not stack'd, malloc'd or (recently) free'd
==2248==
==2248== Process terminating with default action of signal 11 (SIGSEGV)
==2248==  Access not within mapped region at address 0x3A4
==2248==    at 0x45AD7C1: mysql_more_results (in /usr/lib/libmysqlclient.so.14.0.0)
==2248==    by 0x817A480: (within /usr/lib/php5/bin/php)
==2248==    by 0x82D6995: zend_objects_store_free_object_storage (in /usr/lib/php5/bin/php)
==2248==    by 0x82B6943: shutdown_executor (in /usr/lib/php5/bin/php)
==2248==    by 0x82C0A2A: zend_deactivate (in /usr/lib/php5/bin/php)
==2248==    by 0x8288BD0: php_request_shutdown (in /usr/lib/php5/bin/php)
==2248==    by 0x8328D9F: main (in /usr/lib/php5/bin/php)
==2248==
==2248== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 83 from 2)
==2248== malloc/free: in use at exit: 1,289,654 bytes in 23,258 blocks.
==2248== malloc/free: 31,257 allocs, 7,999 frees, 2,985,071 bytes allocated.
==2248== For counts of detected errors, rerun with: -v
==2248== searching for pointers to 23,258 not-freed blocks.
==2248== checked 3,606,460 bytes.
==2248==
==2248== LEAK SUMMARY:
==2248==    definitely lost: 0 bytes in 0 blocks.
==2248==      possibly lost: 0 bytes in 0 blocks.
==2248==    still reachable: 1,289,654 bytes in 23,258 blocks.
==2248==         suppressed: 0 bytes in 0 blocks.
==2248== Reachable blocks (those to which a pointer was found) are not shown.
==2248== To see them, rerun with: --show-reachable=yes


This is running PHP 5.1.4 on Gentoo GNU/Linux

Can be this a problem with libmysqlclient?

Thanks
 [2006-09-08 14:38 UTC] dan at geminisbs dot com
I'm also having this problem on Fedora Core 5 x64, PHP 5.1.4. My backtrace:

#0  0x00002acef62a61d0 in mysql_more_results () from /usr/lib64/mysql/libmysqlclient.so.15
#1  0x00002acefa939f1f in _pdo_mysql_error () from /usr/lib64/php/modules/pdo_mysql.so
#2  0x00002acefa829515 in pdo_row_new () from /usr/lib64/php/modules/pdo.so
#3  0x00002acef6d875fb in zend_objects_store_free_object_storage () from /etc/httpd/modules/libphp5.so
#4  0x00002acef6d61b2c in shutdown_executor () from /etc/httpd/modules/libphp5.so
#5  0x00002acef6d6cd77 in zend_deactivate () from /etc/httpd/modules/libphp5.so
#6  0x00002acef6d2ef7a in php_request_shutdown () from /etc/httpd/modules/libphp5.so
#7  0x00002acef6dea3f3 in php_ap2_register_hook () from /etc/httpd/modules/libphp5.so
#8  0x000055555557e1ba in ap_run_handler () from /usr/sbin/httpd
#9  0x0000555555581612 in ap_invoke_handler () from /usr/sbin/httpd
#10 0x000055555558bd2a in ap_internal_redirect () from /usr/sbin/httpd
#11 0x00002acef5410f00 in ?? () from /etc/httpd/modules/mod_rewrite.so
#12 0x000055555557e1ba in ap_run_handler () from /usr/sbin/httpd
#13 0x0000555555581612 in ap_invoke_handler () from /usr/sbin/httpd
#14 0x000055555558bed8 in ap_process_request () from /usr/sbin/httpd
#15 0x0000555555589160 in ap_register_input_filter () from /usr/sbin/httpd
#16 0x00005555555853f2 in ap_run_process_connection () from /usr/sbin/httpd
#17 0x000055555558fadb in ap_graceful_stop_signalled () from /usr/sbin/httpd
#18 0x000055555558fd6a in ap_graceful_stop_signalled () from /usr/sbin/httpd
#19 0x000055555558fe20 in ap_graceful_stop_signalled () from /usr/sbin/httpd
#20 0x0000555555590b16 in ap_mpm_run () from /usr/sbin/httpd
#21 0x000055555556b784 in main () from /usr/sbin/httpd

Other things of note:
APC seems to effect the problem. If I'm running APC 3.0.10 I do not get this. The moment I install APC >3.0.10 I get this segfault on every request.
 [2006-11-20 16:19 UTC] adam dot huttler at fracturedatlas dot org
Exact same problem here, including the experience with APC > 3.0.10. Any idea when a fix can be expected?  Thanks.
 [2008-05-08 10:57 UTC] johannes at schlueters dot de
See also http://bugs.php.net/bug.php?id=42499
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 08:01:29 2024 UTC