[PHP-BUG] Bug #53007 [NEW]: crash when result set contains NULL
From: Operating system: ubuntu 10.4 amd64 PHP version: 5.3.3 Package: ODBC related Bug Type: Bug Bug description:crash when result set contains NULL Description: PHP (CLI) crashes (Segfault) on a NULL in the result set. - latest easysoft odbc-odbc bridge and unixODBC-2.3.0 (compiled from source) - php-5.3.3 compiled from source (--with-unixODBC) Database is a PROGRESS OPENEDGE 10.1C database. Actual result: -- #0 0x75386085 in memcpy () from /lib/libc.so.6 #1 0x006dee08 in _estrndup (s=0x1331c08 "\030\034\063\001", length= ) at /usr/include/bits/string3.h:52 #2 0x00579b6a in zif_odbc_result (ht=, return_value=0x1332c60, return_value_ptr=, this_ptr=, return_value_used=) at /usr/src/php-5.3.3/ext/odbc/php_odbc.c:2110 #3 0x00746a3c in zend_do_fcall_common_helper_SPEC (execute_data=0x77e8ab58) at /usr/src/php-5.3.3/Zend/zend_vm_execute.h:316 #4 0x0071ebd8 in execute (op_array=0x10b4380) at /usr/src/php- 5.3.3/Zend/zend_vm_execute.h:107 #5 0x006f982a in zend_execute_scripts (type=8, retval=, file_count=3) at /usr/src/php-5.3.3/Zend/zend.c:1194 #6 0x006a80ed in php_execute_script (primary_file=) at /usr/src/php-5.3.3/main/main.c:2260 #7 0x0078064e in main (argc=, argv=) at /usr/src/php-5.3.3/sapi/cli/php_cli.c:1192 -- Edit bug report at http://bugs.php.net/bug.php?id=53007&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53007&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53007&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53007&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53007&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53007&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53007&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53007&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53007&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53007&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53007&r=support Expected behavior: http://bugs.php.net/fix.php?id=53007&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53007&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53007&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53007&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53007&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53007&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53007&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53007&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53007&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53007&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53007&r=mysqlcfg
Bug #52554 [Com]: Sporadic PHP Segmentation fault in combination with unixODBC
Edit report at http://bugs.php.net/bug.php?id=52554&edit=1
ID: 52554
Comment by: crewone at gmail dot com
Reported by:cameron dot moller at gmail dot com
Summary:Sporadic PHP Segmentation fault in combination with
unixODBC
Status: Feedback
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:
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 0x75386085 in memcpy () from /lib/libc.so.6
#1 0x006dee08 in _estrndup (s=0x1331c08 "\030\034\063\001",
length=
) at /usr/include/bits/string3.h:52
#2 0x00579b6a in zif_odbc_result (ht=,
return_value=0x1332c60, return_value_ptr=,
this_ptr=, return_value_used=)
at /usr/src/php-5.3.3/ext/odbc/php_odbc.c:2110
#3 0x00746a3c in zend_do_fcall_common_helper_SPEC
(execute_data=0x77e8ab58) at
/usr/src/php-5.3.3/Zend/zend_vm_execute.h:316
#4 0x0071ebd8 in execute (op_array=0x10b4380) at /usr/src/php-
5.3.3/Zend/zend_vm_execute.h:107
#5 0x006f982a in zend_execute_scripts (type=8, retval=, file_count=3) at /usr/src/php-5.3.3/Zend/zend.c:1194
#6 0x006a80ed in php_execute_script (primary_file=) at /usr/src/php-5.3.3/main/main.c:2260
#7 0x0078064e in main (argc=, argv=) at /usr/src/php-5.3.3/sapi/cli/php_cli.c:1192
Previous Comments:
[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
Bug #52554 [Com]: Sporadic PHP Segmentation fault in combination with unixODBC
Edit report at http://bugs.php.net/bug.php?id=52554&edit=1
ID: 52554
Comment by: crewone at gmail dot com
Reported by:cameron dot moller at gmail dot com
Summary:Sporadic PHP Segmentation fault in combination with
unixODBC
Status: Feedback
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:
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.
Previous Comments:
----------------
[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 0x75386085 in memcpy () from /lib/libc.so.6
#1 0x006dee08 in _estrndup (s=0x1331c08 "\030\034\063\001",
length=
) at /usr/include/bits/string3.h:52
#2 0x00579b6a in zif_odbc_result (ht=,
return_value=0x1332c60, return_value_ptr=,
this_ptr=, return_value_used=)
at /usr/src/php-5.3.3/ext/odbc/php_odbc.c:2110
#3 0x00746a3c in zend_do_fcall_common_helper_SPEC
(execute_data=0x77e8ab58) at
/usr/src/php-5.3.3/Zend/zend_vm_execute.h:316
#4 0x0071ebd8 in execute (op_array=0x10b4380) at /usr/src/php-
5.3.3/Zend/zend_vm_execute.h:107
#5 0x006f982a in zend_execute_scripts (type=8, retval=, file_count=3) at /usr/src/php-5.3.3/Zend/zend.c:1194
#6 0x006a80ed in php_execute_script (primary_file=) at /usr/src/php-5.3.3/main/main.c:2260
#7 0x0078064e in main (argc=, argv=) 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
Bug #52554 [Com]: Sporadic PHP Segmentation fault in combination with unixODBC
Edit report at http://bugs.php.net/bug.php?id=52554&edit=1 ID: 52554 Comment by: crewone at gmail dot com Reported by:cameron dot moller at gmail dot com Summary:Sporadic PHP Segmentation fault in combination with unixODBC 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: The same bug occurs at or around line 1723. (php_odbc_fetch_hash) The fix is easy using a cast. Previous Comments: [2010-10-09 01:07:32] fel...@php.net There is driver using SQLINTEGER, and others SQLLEN as type for the buffer size pointer. [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 0x75386085 in memcpy () from /lib/libc.so.6 #1 0x006dee08 in _estrndup (s=0x1331c08 "\030\034\063\001", length= ) at /usr/include/bits/string3.h:52 #2 0x00579b6a in zif_odbc_result (ht=, return_value=0x1332c60, return_value_ptr=, this_ptr=, return_value_used=) at /usr/src/php-5.3.3/ext/odbc/php_odbc.c:2110 #3 0x00746a3c in zend_do_fcall_common_helper_SPEC (execute_data=0x77e8ab58) at /usr/src/php-5.3.3/Zend/zend_vm_execute.h:316 #4 0x0071ebd8 in execute (op_array=0x10b4380) at /usr/src/php- 5.3.3/Zend/zend_vm_execute.h:107 #5 0x006f982a in zend_execute_scripts (type=8, retval=, file_count=3) at /usr/src/php-5.3.3/Zend/zend.c:1194 #6 0x006a80ed in php_execute_script (primary_file=) at /usr/src/php-5.3.3/main/main.c:2260 #7 0x0078064e in main (argc=, argv=) 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 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/bug.php?id=52554 -- Edit this bug report at http://bugs.php.net/bug.php?id=52554&edit=1
Bug #53007 [Bgs]: crash when result set contains NULL
Edit report at http://bugs.php.net/bug.php?id=53007&edit=1 ID: 53007 User updated by:crewone at gmail dot com Reported by:crewone at gmail dot com Summary:crash when result set contains NULL Status: Bogus Type: Bug Package:ODBC related Operating System: ubuntu 10.4 amd64 PHP Version:5.3.3 Block user comment: N New Comment: Weird that nobody seems to fix this, even though the fix is simple and available. Previous Comments: [2010-10-30 00:53:57] lindoja at juno dot com I've also experienced ODBC crashing PHP when the result set contains a Null (and sometimes even when it does not). This occurs when accessing NUMBER fields in a Pervasive database via an ODBC DSN. The workaround I found is to add zero or an empty string to the start of the results rather than returning them directly. i.e. instead of 'Select "MyNumber","MyString" FROM "MyTable"', you'd do this: 'Select 0 + "MyNumber" As "MyNumber", '' + "MyString" As "MyString" FROM "MyTable"' [2010-10-07 02:26:15] fel...@php.net Duplicated of bug #52554 [2010-10-07 02:06:10] crewone at gmail dot com Description: PHP (CLI) crashes (Segfault) on a NULL in the result set. - latest easysoft odbc-odbc bridge and unixODBC-2.3.0 (compiled from source) - php-5.3.3 compiled from source (--with-unixODBC) Database is a PROGRESS OPENEDGE 10.1C database. Actual result: -- #0 0x75386085 in memcpy () from /lib/libc.so.6 #1 0x006dee08 in _estrndup (s=0x1331c08 "\030\034\063\001", length= ) at /usr/include/bits/string3.h:52 #2 0x00579b6a in zif_odbc_result (ht=, return_value=0x1332c60, return_value_ptr=, this_ptr=, return_value_used=) at /usr/src/php-5.3.3/ext/odbc/php_odbc.c:2110 #3 0x00746a3c in zend_do_fcall_common_helper_SPEC (execute_data=0x77e8ab58) at /usr/src/php-5.3.3/Zend/zend_vm_execute.h:316 #4 0x0071ebd8 in execute (op_array=0x10b4380) at /usr/src/php- 5.3.3/Zend/zend_vm_execute.h:107 #5 0x006f982a in zend_execute_scripts (type=8, retval=, file_count=3) at /usr/src/php-5.3.3/Zend/zend.c:1194 #6 0x006a80ed in php_execute_script (primary_file=) at /usr/src/php-5.3.3/main/main.c:2260 #7 0x0078064e in main (argc=, argv=) at /usr/src/php-5.3.3/sapi/cli/php_cli.c:1192 -- Edit this bug report at http://bugs.php.net/bug.php?id=53007&edit=1
