php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #37445 Reproducible segfault
Submitted: 2006-05-15 10:01 UTC Modified: 2010-12-20 12:12 UTC
Votes:29
Avg. Score:4.7 ± 0.6
Reproduced:27 of 27 (100.0%)
Same Version:21 (77.8%)
Same OS:18 (66.7%)
From: dhrubab at gmail dot com Assigned: iliaa
Status: Closed Package: MySQL related
PHP Version: 5.1.4 OS: Linux
Private report: No CVE-ID:
 [2006-05-15 10:01 UTC] dhrubab at gmail dot com
Description:
------------
The provided code causes a segfault.

My php.ini settings are as below.

short_open_tag = Off
allow_call_time_pass_reference = Off
error_reporting  =  E_ALL
display_errors = On
display_startup_errors = On
log_errors = Off
variables_order = "GPCS"
register_globals = Off
register_long_arrays = Off
register_argc_argv = Off
magic_quotes_gpc = Off
magic_quotes_runtime = Off
allow_url_fopen = On
session.name = GRTSESSID
session.use_trans_sid = 0
session.hash_function = 1
session.hash_bits_per_character = 5

My configure is as below.

'./configure' '--prefix=/usr/lib/php5' '--sysconfdir=/etc' '--cache-file=./config.cache' '--disable-cli' '--with-apxs2=/usr/sbin/apxs2' '--with-config-file-path=/etc/php/apache2-php5' '--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active' '--without-pear' '--disable-bcmath' '--with-bz2=shared' '--enable-calendar=shared' '--with-curl=shared' '--with-curlwrappers=shared' '--disable-dbase' '--enable-exif=shared' '--without-fbsql' '--without-fdftk' '--disable-filepro' '--enable-ftp=shared' '--with-gettext=shared' '--without-gmp' '--without-hwapi' '--without-informix' '--disable-ipv6' '--without-kerberos' '--enable-mbstring=shared' '--with-mcrypt=shared' '--disable-memory-limit' '--with-mhash=shared' '--without-ming' '--without-msql' '--without-mssql' '--with-ncurses=shared' '--with-openssl' '--with-openssl-dir=/usr' '--enable-pcntl=shared' '--disable-pdo' '--without-pgsql' '--with-pspell=shared' '--without-recode' '--disable-shmop' '--without-snmp' '--enable-soap=shared' '--enable-sockets=shared' '--without-sybase' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--with-tidy=shared' '--enable-wddx=shared' '--with-xmlrpc=shared' '--with-xsl=shared' '--with-zlib=shared' '--enable-debug' '--without-cdb' '--without-db4' '--without-flatfile' '--without-gdbm' '--without-inifile' '--without-qdbm' '--with-freetype-dir=/usr' '--with-t1lib=/usr' '--disable-gd-jis-conv' '--enable-gd-native-ttf' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--without-xpm-dir' '--with-gd' '--with-imap=shared' '--with-imap-ssl' '--with-mysql=shared,/usr/lib/mysql' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=shared,/usr/bin/mysql_config' '--with-readline' '--without-libedit' '--without-mm' '--enable-sqlite-utf8'

My full phpinfo() is below.

http://www.dhruba.net/files/segfault.phpinfo.html

This is simply one example of a segfault.  Our application is segfaulting left, right and centre and I am trying to narrow down other test cases that result in segfaults.  The main point is that PHP or PDO whichever is the culprit is not giving error messages or exceptions as it should when there's something wrong and instead segfaulting.  When you use a method name that doesn't exist or a class constant that doesn't exist or when you violate allow_call_time_pass_reference = Off then a segfault occurs.  This has been reproduced on three machines with three different linux distributions.

Reproduce code:
---------------
The source code is below.

http://www.dhruba.net/files/segfault.php

Expected result:
----------------
It should give me an error about passing a string by reference in bindParam().

Actual result:
--------------
It segfaults.  Backtrace is below.

sepoy ~ # gdb /usr/sbin/apache2
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run -X -D DEFAULT_VHOST -D PHP5 -D INFO -D USERDIR -d /usr/lib/apache2 -f /etc/apache2/httpd.conf -k start 
Starting program: /usr/sbin/apache2 -X -D DEFAULT_VHOST -D PHP5 -D INFO -D USERDIR -d /usr/lib/apache2 -f /etc/apache2/httpd.conf -k start
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 4165)]
[Mon May 15 10:40:27 2006] [warn] NameVirtualHost *:80 has no VirtualHosts

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 4165)]
0xb6e1025d in mysql_more_results () from /usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0xb6e1025d in mysql_more_results () from /usr/lib/libmysqlclient.so.15
#1  0xb6ddb9b9 in free_statement (stmt=0x82c10cc)
    at /var/tmp/portage/pecl-pdo-1.0.3/work/PDO-1.0.3/pdo_stmt.c:2200
#2  0xb6ddbb6c in php_pdo_stmt_delref (stmt=0x5a5a5a5a)
    at /var/tmp/portage/pecl-pdo-1.0.3/work/PDO-1.0.3/pdo_stmt.c:2239
#3  0xb6ddbb8b in pdo_dbstmt_free_storage (stmt=0x5a5a5a5a)
    at /var/tmp/portage/pecl-pdo-1.0.3/work/PDO-1.0.3/pdo_stmt.c:2245
#4  0xb78eae78 in zend_objects_store_free_object_storage (objects=0xb7a65bac)
    at /var/tmp/portage/php-5.1.4/work/php-5.1.4/Zend/zend_objects_API.c:86
#5  0xb78c0501 in shutdown_executor ()
    at /var/tmp/portage/php-5.1.4/work/php-5.1.4/Zend/zend_execute_API.c:281
#6  0xb78ce7a2 in zend_deactivate ()
    at /var/tmp/portage/php-5.1.4/work/php-5.1.4/Zend/zend.c:854
#7  0xb788a816 in php_request_shutdown (dummy=0x0)
    at /var/tmp/portage/php-5.1.4/work/php-5.1.4/main/main.c:1287
#8  0xb796e64c in php_apache_request_dtor (r=0x82aecd8)
    at /var/tmp/portage/php-5.1.4/work/php-5.1.4/sapi/apache2handler/sapi_apache2.c:445
#9  0xb796ecad in php_handler (r=0x82aecd8)
    at /var/tmp/portage/php-5.1.4/work/php-5.1.4/sapi/apache2handler/sapi_apache2.c:603
#10 0x08068ed5 in ap_run_handler (r=0x82aecd8) at config.c:152
#11 0x0806941f in ap_invoke_handler (r=0x82aecd8) at config.c:364
#12 0x08065ea7 in ap_process_request (r=0x82aecd8) at http_request.c:249
#13 0x08060dbc in ap_process_http_connection (c=0x82a8b30) at http_core.c:251
#14 0x08072e59 in ap_run_process_connection (c=0x82a8b30) at connection.c:43
#15 0x0807316e in ap_process_connection (c=0x82a8b30, csd=0x5a5a5a5a)
    at connection.c:176
#16 0x08067666 in child_main (child_num_arg=1515870810) at prefork.c:610
#17 0x08067746 in make_child (s=0x82c10cc, slot=0) at prefork.c:650
#18 0x08067880 in startup_children (number_to_start=5) at prefork.c:722
#19 0x08067caf in ap_mpm_run (_pconf=0x80a1e58, plog=0x80cdf08, s=0x5)
    at prefork.c:941
#20 0x0806e986 in main (argc=16, argv=0xbfc52894) at main.c:618
(gdb) 


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-05-15 10:20 UTC] dhrubab at gmail dot com
A note to say I'm using latest php (5.1.4), mysql (5.0.21), pecl-pdo (1.0.3) and pecl-pdo-mysql (1.0.2).  The example code relies on mysql5 default tables being there.
 [2006-05-15 12:40 UTC] indeyets at gmail dot com
reverting this diff helps to solve problem, while the proper resolution is not available:
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-19 09:21 UTC] greg dot smith at gr-tech dot net
I have reproduced the bug on Centos 4 64bit and 32 bit and Fedora core 5 as well as Suse 10.1
 [2006-05-26 00:56 UTC] php at seven dot net dot nz
I too was going nuts from this bug. I know no C so I can't help too much, but here's my GDB trace for people that understand it. So far I can't narrow down exactly what code is causing the segfault. Reverting the diff as suggested by indeyets at gmail dot com solved the problem.

./configure --enable-debug --with-apxs2=/usr/bin/apxs2 --with-zlib --with-bz2 --with-gd --with-ttf --with-pdo-mysql --with-mysql --with-xmlrpc --with-curl

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1214347584 (LWP 14636)]
0xb7401950 in mysql_more_results () from /usr/lib/libmysqlclient.so.15
(gdb) where
#0  0xb7401950 in mysql_more_results () from /usr/lib/libmysqlclient.so.15
#1  0xb76ff78c in pdo_mysql_stmt_dtor (stmt=0x8399a74) at /tmp/php-5.1.4/ext/pdo_mysql/mysql_statement.c:71
#2  0xb76f9713 in free_statement (stmt=0x8399a74) at /tmp/php-5.1.4/ext/pdo/pdo_stmt.c:2200
#3  0xb786485b in zend_objects_store_free_object_storage (objects=0xb79e396c) at /tmp/php-5.1.4/Zend/zend_objects_API.c:86
#4  0xb783b851 in shutdown_executor () at /tmp/php-5.1.4/Zend/zend_execute_API.c:281
#5  0xb7848645 in zend_deactivate () at /tmp/php-5.1.4/Zend/zend.c:854
#6  0xb7806229 in php_request_shutdown (dummy=0x0) at /tmp/php-5.1.4/main/main.c:1287
#7  0xb78e71b7 in php_handler (r=0x82af068) at /tmp/php-5.1.4/sapi/apache2handler/sapi_apache2.c:445
#8  0x08077e38 in ap_run_handler ()
#9  0x080781bc in ap_invoke_handler ()
#10 0x080698c3 in ap_internal_redirect ()
#11 0xb717cc03 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so
#12 0x082af058 in ?? ()
#13 0x082a66b0 in ?? ()
#14 0x00000000 in ?? ()
 [2006-05-26 08:51 UTC] dhrubab at gmail dot com
Has analysis of this problem been started?
 [2006-05-27 09:56 UTC] dhrubab at gmail dot com
The two urls I provided were broken for a while but have now been relocated to the following two urls.  Sorry for any inconvenience.

Source: http://static.dhruba.net/bugs/37445.src.html
Phpinfo: http://static.dhruba.net/bugs/37445.phpinfo.html

I should also mention that I've been getting futher segfaults being caused by a variety of very different code.  For example doing var_dump(); followed by exit; within a loop is causing a segfault.  I'm not able to reproduce with smaller test cases.   Is it okay if I give you a trace for the segfault from my own application since the smaller test cases are sometimes quite difficult to produce?
 [2006-05-27 13:47 UTC] pajoye@php.net
    $oDB= new PDO('mysql:host=localhost;dbname=yourdb', 'user', 'pass');

// emulated or not does not matter
    $oDB->setAttribute(PDO :: ATTR_EMULATE_PREPARES, true);
    $oStm = $oDB->prepare("SELECT * FROM tbl WHERE xyz=:character_set");
   $oStm->bindParam(':character_set', 'foo);


For the record, the problem here is only about how PDO manages to free its resource when a fatal error or exit() occurs.

In this example, it is a fatal error raise with the bindParam call (it expects a variable as it uses a reference).

The problem is the same in many other bug reports (unexpected script exist, like exit() in a function). The solution is to always set query_stmt in the dbh struct, and add another flag to define  if there was an error or not.

I have patches that fix the problem for mysql. To be sure I don't break something in the working drivers, I have to install pgsql.
 [2006-06-03 20:07 UTC] aidan@php.net
Same here, Debian Sarge AMD64

# gdb /usr/sbin/apache2
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-linux"...(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
 
(gdb) run -X
Starting program: /usr/sbin/apache2 -X
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 182925889008 (LWP 27843)]
 
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182925889008 (LWP 27843)]
0x0000002a9a67e717 in mysql_more_results () from /usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x0000002a9a67e717 in mysql_more_results () from /usr/lib/libmysqlclient.so.15
#1  0x0000002a9a55a141 in pdo_mysql_stmt_dtor (stmt=0x82e2c8) at /tmp/tmpDAHJQf/PDO_MYSQL-1.0.2/mysql_statement.c:71
#2  0x0000002a9a44c730 in free_statement (stmt=0x82e2c8) at /tmp/tmpTQaDT7/PDO-1.0.3/pdo_stmt.c:2200
#3  0x0000002a9a44c7e9 in pdo_dbstmt_free_storage (stmt=0x82bc60) at /tmp/tmpTQaDT7/PDO-1.0.3/pdo_stmt.c:2245
#4  0x0000002a9820702e in zend_objects_store_del_ref () from /usr/lib/apache2/modules/libphp5.so
#5  0x0000002a981edcc0 in _zval_dtor_func () from /usr/lib/apache2/modules/libphp5.so
#6  0x0000002a981e44e9 in _zval_ptr_dtor () from /usr/lib/apache2/modules/libphp5.so
#7  0x0000002a98209143 in execute () from /usr/lib/apache2/modules/libphp5.so
#8  0x0000002a982089bc in execute () from /usr/lib/apache2/modules/libphp5.so
#9  0x0000002a98208edc in execute () from /usr/lib/apache2/modules/libphp5.so
#10 0x0000002a982089bc in execute () from /usr/lib/apache2/modules/libphp5.so
#11 0x0000002a9820c6d8 in execute () from /usr/lib/apache2/modules/libphp5.so
#12 0x0000002a982089bc in execute () from /usr/lib/apache2/modules/libphp5.so
#13 0x0000002a981ef907 in zend_execute_scripts () from /usr/lib/apache2/modules/libphp5.so
#14 0x0000002a981b66a2 in php_execute_script () from /usr/lib/apache2/modules/libphp5.so
#15 0x0000002a98254768 in zend_get_zval_ptr_ptr () from /usr/lib/apache2/modules/libphp5.so
#16 0x0000000000434b71 in ap_run_handler ()
#17 0x0000000000435199 in ap_invoke_handler ()
#18 0x00000000004278a6 in ap_process_request ()
#19 0x00000000004234ac in _start ()
#20 0x000000000043f181 in ap_run_process_connection ()
#21 0x00000000004333ee in ap_graceful_stop_signalled ()
#22 0x00000000004335ae in ap_graceful_stop_signalled ()
#23 0x0000000000433615 in ap_graceful_stop_signalled ()
#24 0x0000000000433d2c in ap_mpm_run ()
#25 0x0000000000439be7 in main ()
(gdb) frame 7
#7  0x0000002a98209143 in execute () from /usr/lib/apache2/modules/libphp5.so
(gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name
$1 = 0x2a9a44e3e5 "query"
(gdb) print (char *)executor_globals.active_op_array->function_name
$2 = 0x82a288 "Database"
 [2006-06-03 20:13 UTC] aidan@php.net
Reverting mysql_statement.c from 1.48.2.13 to 1.48.2.12 did not fix the problem for me.
 [2006-06-29 10:37 UTC] mark-phpbug at vetrex dot org dot uk
I also have this problem but using bindValue() instead of bindParam()
 [2006-07-31 20:20 UTC] iliaa@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 [2010-12-20 12:12 UTC] jani@php.net
-Package: Tidy +Package: MySQL related -Assigned To: +Assigned To: iliaa
 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Sat Apr 19 14:01:50 2014 UTC