#37445 [Asn]: Reproducible segfault
ID: 37445
Updated by: [EMAIL PROTECTED]
Reported By: dhrubab at gmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.4
Assigned To: wez
New Comment:
Reverting mysql_statement.c from 1.48.2.13 to 1.48.2.12 did not fix the
problem for me.
Previous Comments:
[2006-06-03 20:07:04] [EMAIL PROTECTED]
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)]
0x002a9a67e717 in mysql_more_results () from
/usr/lib/libmysqlclient.so.15
(gdb) bt
#0 0x002a9a67e717 in mysql_more_results () from
/usr/lib/libmysqlclient.so.15
#1 0x002a9a55a141 in pdo_mysql_stmt_dtor (stmt=0x82e2c8) at
/tmp/tmpDAHJQf/PDO_MYSQL-1.0.2/mysql_statement.c:71
#2 0x002a9a44c730 in free_statement (stmt=0x82e2c8) at
/tmp/tmpTQaDT7/PDO-1.0.3/pdo_stmt.c:2200
#3 0x002a9a44c7e9 in pdo_dbstmt_free_storage (stmt=0x82bc60) at
/tmp/tmpTQaDT7/PDO-1.0.3/pdo_stmt.c:2245
#4 0x002a9820702e in zend_objects_store_del_ref () from
/usr/lib/apache2/modules/libphp5.so
#5 0x002a981edcc0 in _zval_dtor_func () from
/usr/lib/apache2/modules/libphp5.so
#6 0x002a981e44e9 in _zval_ptr_dtor () from
/usr/lib/apache2/modules/libphp5.so
#7 0x002a98209143 in execute () from
/usr/lib/apache2/modules/libphp5.so
#8 0x002a982089bc in execute () from
/usr/lib/apache2/modules/libphp5.so
#9 0x002a98208edc in execute () from
/usr/lib/apache2/modules/libphp5.so
#10 0x002a982089bc in execute () from
/usr/lib/apache2/modules/libphp5.so
#11 0x002a9820c6d8 in execute () from
/usr/lib/apache2/modules/libphp5.so
#12 0x002a982089bc in execute () from
/usr/lib/apache2/modules/libphp5.so
#13 0x002a981ef907 in zend_execute_scripts () from
/usr/lib/apache2/modules/libphp5.so
#14 0x002a981b66a2 in php_execute_script () from
/usr/lib/apache2/modules/libphp5.so
#15 0x002a98254768 in zend_get_zval_ptr_ptr () from
/usr/lib/apache2/modules/libphp5.so
#16 0x00434b71 in ap_run_handler ()
#17 0x00435199 in ap_invoke_handler ()
#18 0x004278a6 in ap_process_request ()
#19 0x004234ac in _start ()
#20 0x0043f181 in ap_run_process_connection ()
#21 0x004333ee in ap_graceful_stop_signalled ()
#22 0x004335ae in ap_graceful_stop_signalled ()
#23 0x00433615 in ap_graceful_stop_signalled ()
#24 0x00433d2c in ap_mpm_run ()
#25 0x00439be7 in main ()
(gdb) frame 7
#7 0x002a98209143 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-05-27 13:47:53] [EMAIL PROTECTED]
$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-05-27 09:56:46] 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.phpin
#37445 [Asn]: Reproducible segfault
ID: 37445
Updated by: [EMAIL PROTECTED]
Reported By: dhrubab at gmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.4
Assigned To: wez
New Comment:
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)]
0x002a9a67e717 in mysql_more_results () from
/usr/lib/libmysqlclient.so.15
(gdb) bt
#0 0x002a9a67e717 in mysql_more_results () from
/usr/lib/libmysqlclient.so.15
#1 0x002a9a55a141 in pdo_mysql_stmt_dtor (stmt=0x82e2c8) at
/tmp/tmpDAHJQf/PDO_MYSQL-1.0.2/mysql_statement.c:71
#2 0x002a9a44c730 in free_statement (stmt=0x82e2c8) at
/tmp/tmpTQaDT7/PDO-1.0.3/pdo_stmt.c:2200
#3 0x002a9a44c7e9 in pdo_dbstmt_free_storage (stmt=0x82bc60) at
/tmp/tmpTQaDT7/PDO-1.0.3/pdo_stmt.c:2245
#4 0x002a9820702e in zend_objects_store_del_ref () from
/usr/lib/apache2/modules/libphp5.so
#5 0x002a981edcc0 in _zval_dtor_func () from
/usr/lib/apache2/modules/libphp5.so
#6 0x002a981e44e9 in _zval_ptr_dtor () from
/usr/lib/apache2/modules/libphp5.so
#7 0x002a98209143 in execute () from
/usr/lib/apache2/modules/libphp5.so
#8 0x002a982089bc in execute () from
/usr/lib/apache2/modules/libphp5.so
#9 0x002a98208edc in execute () from
/usr/lib/apache2/modules/libphp5.so
#10 0x002a982089bc in execute () from
/usr/lib/apache2/modules/libphp5.so
#11 0x002a9820c6d8 in execute () from
/usr/lib/apache2/modules/libphp5.so
#12 0x002a982089bc in execute () from
/usr/lib/apache2/modules/libphp5.so
#13 0x002a981ef907 in zend_execute_scripts () from
/usr/lib/apache2/modules/libphp5.so
#14 0x002a981b66a2 in php_execute_script () from
/usr/lib/apache2/modules/libphp5.so
#15 0x002a98254768 in zend_get_zval_ptr_ptr () from
/usr/lib/apache2/modules/libphp5.so
#16 0x00434b71 in ap_run_handler ()
#17 0x00435199 in ap_invoke_handler ()
#18 0x004278a6 in ap_process_request ()
#19 0x004234ac in _start ()
#20 0x0043f181 in ap_run_process_connection ()
#21 0x004333ee in ap_graceful_stop_signalled ()
#22 0x004335ae in ap_graceful_stop_signalled ()
#23 0x00433615 in ap_graceful_stop_signalled ()
#24 0x00433d2c in ap_mpm_run ()
#25 0x00439be7 in main ()
(gdb) frame 7
#7 0x002a98209143 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"
Previous Comments:
[2006-05-27 13:47:53] [EMAIL PROTECTED]
$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-05-27 09:56:46] 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 segfaul
#37445 [Asn]: Reproducible segfault
ID: 37445
Updated by: [EMAIL PROTECTED]
Reported By: dhrubab at gmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.4
Assigned To: wez
New Comment:
$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.
Previous Comments:
[2006-05-27 09:56:46] 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-26 08:51:04] dhrubab at gmail dot com
Has analysis of this problem been started?
[2006-05-26 00:56:46] 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 0x in ?? ()
[2006-05-19 09:21:12] 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-15 12:40:11] 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
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/37445
--
Edit this bug report at http://bugs.php.net/?id=37445&edit=1
#37445 [Asn]: Reproducible segfault
ID: 37445 User updated by: dhrubab at gmail dot com Reported By: dhrubab at gmail dot com Status: Assigned Bug Type: PDO related Operating System: Linux PHP Version: 5.1.4 Assigned To: wez New Comment: 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? Previous Comments: [2006-05-26 08:51:04] dhrubab at gmail dot com Has analysis of this problem been started? [2006-05-26 00:56:46] 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 0x in ?? () [2006-05-19 09:21:12] 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-15 12:40:11] 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-15 10:20:58] 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. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/37445 -- Edit this bug report at http://bugs.php.net/?id=37445&edit=1
#37445 [Asn]: Reproducible segfault
ID: 37445 User updated by: dhrubab at gmail dot com Reported By: dhrubab at gmail dot com Status: Assigned Bug Type: PDO related Operating System: Linux PHP Version: 5.1.4 Assigned To: wez New Comment: Has analysis of this problem been started? Previous Comments: [2006-05-26 00:56:46] 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 0x in ?? () [2006-05-19 09:21:12] 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-15 12:40:11] 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-15 10:20:58] 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 10:01:57] 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' '
#37445 [Asn]: Reproducible segfault
ID: 37445 User updated by: dhrubab at gmail dot com Reported By: dhrubab at gmail dot com Status: Assigned Bug Type: PDO related Operating System: Linux PHP Version: 5.1.4 Assigned To: wez New Comment: 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. Previous Comments: [2006-05-15 10:01:57] 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 fr
