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 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
------------------------------------------------------------------------
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
