Edit report at http://bugs.php.net/bug.php?id=52554&edit=1
ID: 52554
Updated by: fel...@php.net
Reported by: cameron dot moller at gmail dot com
Summary: Sporadic PHP Segmentation fault in combination with
unixODBC
-Status: Feedback
+Status: Open
Type: Bug
Package: ODBC related
Operating System: 2.6.34-gentoo-r1 x86_64
PHP Version: 5.3SVN-2010-08-06 (SVN)
Block user comment: N
New Comment:
There is driver using SQLINTEGER, and others SQLLEN as type for the
buffer size pointer.
Previous Comments:
------------------------------------------------------------------------
[2010-10-07 09:11:32] crewone at gmail dot com
After debugging I found that:
result->values[field_ind].vallen = -1
But...
result->values[field_ind].vallen is a 32-bit integer (4 bytes)
And..
SQLLEN is defined as an 64-bit integer.
Therefore the if statement...
if( result->values[field_ind].vallen == SQL_NULL_DATA )
Fails even if both values are "-1" (SQL_NULL_DATA)
As a result "-1" gets passed to a memcpy and the process segfaults.
The obvious fix would be to cast both sides of the equasion to (int):
if ((int)result->values[field_ind].vallen == (int)SQL_NULL_DATA)
Which seems to work. I'm not sure if it violates any PHP coding
standards, but
that's my fix for now. I trust the maintainer of the odbc code has
enough
information now to create a real fix.
------------------------------------------------------------------------
[2010-10-07 02:39:20] crewone at gmail dot com
I can reproduce this with a result set containing NULL. I wouldn't call
it
'sporadic', in fact it is quite a show stopper for me.
The backtrace:
#0 0x00007ffff5386085 in memcpy () from /lib/libc.so.6
#1 0x00000000006dee08 in _estrndup (s=0x1331c08 "\030\034\063\001",
length=
<value optimized out>) at /usr/include/bits/string3.h:52
#2 0x0000000000579b6a in zif_odbc_result (ht=<value optimized out>,
return_value=0x1332c60, return_value_ptr=<value optimized out>,
this_ptr=<value
optimized out>, return_value_used=<value optimized out>)
at /usr/src/php-5.3.3/ext/odbc/php_odbc.c:2110
#3 0x0000000000746a3c in zend_do_fcall_common_helper_SPEC
(execute_data=0x7ffff7e8ab58) at
/usr/src/php-5.3.3/Zend/zend_vm_execute.h:316
#4 0x000000000071ebd8 in execute (op_array=0x10b4380) at /usr/src/php-
5.3.3/Zend/zend_vm_execute.h:107
#5 0x00000000006f982a in zend_execute_scripts (type=8, retval=<value
optimized
out>, file_count=3) at /usr/src/php-5.3.3/Zend/zend.c:1194
#6 0x00000000006a80ed in php_execute_script (primary_file=<value
optimized
out>) at /usr/src/php-5.3.3/main/main.c:2260
#7 0x000000000078064e in main (argc=<value optimized out>, argv=<value
optimized out>) at /usr/src/php-5.3.3/sapi/cli/php_cli.c:1192
------------------------------------------------------------------------
[2010-08-07 17:40:15] fel...@php.net
That _estrndup on backtrace must be related to RETURN_STRINGL macro used
in the zif_odbc_result... Can you check in which RETURN_STRINGL the
crash occurs and get the string size passed to estrndup()?
------------------------------------------------------------------------
[2010-08-07 12:08:50] cameron dot moller at gmail dot com
Re-emergeing glibc did not help
------------------------------------------------------------------------
[2010-08-06 12:27:31] cameron dot moller at gmail dot com
Description:
------------
Gentoo Linux x86_64
Kernel 2.6.34-gentoo-r1
unixODBC-2.3.0
freeTDS 0.64
PHP 5.3.2 (from Gentoo portage (~ = experimental))
(problem started on PHP 5.2.13 - I upgraded to ~5.3.2)
Apache 2.2.15
gcc 4.4.3-r2
glibc 2.11.2
MSSQL 2005 (remote server)
I have multiple pages that query the database successfully. However, 2
queries always result in a segmentation fault. I ran the page through
gdb and generated a backtrace. Shown below.
The suspect sql is simply "select distinct asgn_group from
csc_report_active order by asgn_group asc"
FYI - sql via isql gives me 773 rows - no problems.
php.ini is vanilla - no changes - but dated Jul 30 - about when the
problem started. Though I do not remember ever making any changes to
php.ini
httpd.conf also vanilla as is /etc/conf.d/apache2
[I] dev-lang/php
Available versions: (5) 5.2.13 ~5.2.14 (~)5.3.2 ~5.3.3
{adabas apache2 bcmath berkdb birdstep bzip2 calendar cdb cgi
cjk (+)cli concurrentmodphp crypt (+)ctype curl curlwrappers db2 dbase
dbmaker debug discard-path doc embed empress empress-bcs enchant esoob
exif fastbuild fdftk +fileinfo (+)filter firebird flatfile
force-cgi-redirect fpm frontbase ftp gd gd-external gdbm gmp (+)hash
(+)iconv imap inifile interbase intl iodbc ipv6 java-external (+)json
kerberos kolab ldap ldap-sasl libedit mcve mhash msql mssql mysql mysqli
mysqlnd ncurses nls oci8 oci8-instant-client odbc pcntl (+)pcre pdo
+phar pic (+)posix postgres qdbm readline recode reflection sapdb
(+)session sharedext sharedmem (+)simplexml snmp soap sockets solid
spell spl sqlite sqlite3 ssl suhosin sybase sybase-ct sysvipc threads
tidy (+)tokenizer truetype unicode wddx xml xmlreader xmlrpc xmlwriter
xpm xsl yaz zip zlib}
Installed versions: 5.3.2(5)(08:26:30 07/30/10)(apache2 berkdb
bzip2 cli crypt ctype fileinfo filter gd gdbm hash iconv imap json
kerberos ldap mssql mysql nls odbc phar posix postgres readline session
simplexml ssl tokenizer truetype unicode xml zlib -adabas -bcmath
-birdstep -calendar -cdb -cgi -cjk -concurrentmodphp -curl -curlwrappers
-db2 -dbmaker -debug -doc -embed -empress -empress-bcs -enchant -esoob
-exif -firebird -flatfile -frontbase -ftp -gd-external -gmp -inifile
-interbase -intl -iodbc -ipv6 -kolab -ldap-sasl -libedit -mysqli
-mysqlnd -oci8 -oci8-instant-client -pcntl -pdo -pic -qdbm -recode
-sapdb -sharedext -sharedmem -snmp -soap -sockets -solid -spell -sqlite
-sqlite3 -suhosin -sybase-ct -sysvipc -threads -tidy -wddx -xmlreader
-xmlrpc -xmlwriter -xpm -xsl -zip)
gdb /usr/bin/php
warning: Can not parse XML syscalls information; XML support was
disabled at compile time.
GNU gdb (Gentoo 7.0.1 p1) 7.0.1
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /usr/bin/php...(no debugging symbols
found)...done.
(gdb) r ccc_assign_groups_activity.php
Starting program: /usr/bin/php ccc_assign_groups_activity.php
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff26cd15a in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff26cd15a in memcpy () from /lib/libc.so.6
#1 0x0000000000644412 in _estrndup ()
#2 0x00000000005474c8 in zif_odbc_result ()
#3 0x00000000006828ff in ?? ()
#4 0x000000000067d747 in execute ()
#5 0x000000000065bf7f in zend_execute_scripts ()
#6 0x000000000061205d in php_execute_script ()
#7 0x00000000006d569c in main ()
(gdb)
I am re-emergeing glibc just to see what happens.
Actual result:
--------------
gdb /usr/bin/php
warning: Can not parse XML syscalls information; XML support was
disabled at compile time.
GNU gdb (Gentoo 7.0.1 p1) 7.0.1
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /usr/bin/php...(no debugging symbols
found)...done.
(gdb) r ccc_assign_groups_activity.php
Starting program: /usr/bin/php ccc_assign_groups_activity.php
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff26cd15a in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff26cd15a in memcpy () from /lib/libc.so.6
#1 0x0000000000644412 in _estrndup ()
#2 0x00000000005474c8 in zif_odbc_result ()
#3 0x00000000006828ff in ?? ()
#4 0x000000000067d747 in execute ()
#5 0x000000000065bf7f in zend_execute_scripts ()
#6 0x000000000061205d in php_execute_script ()
#7 0x00000000006d569c in main ()
(gdb)
I am re-emergeing glibc just to see what happens.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=52554&edit=1
