Bug #52554 [Opn->Csd]: Sporadic PHP Segmentation fault in combination with unixODBC

Edit report at https://bugs.php.net/bug.php?id=52554&edit=1 ID: 52554 Updated by: cmb@php.net Reported by: cameron dot moller at gmail dot com Summary: Sporadic PHP Segmentation fault in combination with unixODBC -Status: Open +Status: Closed Type: Bug Package: ODBC related Operating System: 2.6.34-gentoo-r1 x86_64 PHP Version: 5.3SVN-2010-08-06 (SVN) -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: > result->values[field_ind].vallen is a 32-bit integer (4 bytes) That is no longer the case as of PHP 5.3.11 at least, so this issue should have been resolved. Previous Comments: ------------------------------------------------------------------------ [2010-10-11 10:50:34] crewone at gmail dot com The same bug occurs at or around line 1723. (php_odbc_fetch_hash) The fix is easy using a cast. ------------------------------------------------------------------------ [2010-10-09 01:07:32] felipe@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 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] felipe@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()? ------------------------------------------------------------------------ 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 https://bugs.php.net/bug.php?id=52554 -- Edit this bug report at https://bugs.php.net/bug.php?id=52554&edit=1