I've been fighting with this bug all day long on PHP 5.2.17 *AND* PHP 5.3.16 for 
64-bit Linux.

I have isolated the problem to odbc_fetch_array() for result sets that contain 
an anonymous (unnamed) column with a NULL value. If NULL value is aliased 
("SELECT NULL as SOMETHING") there is no crash.  If an anonymous (unnamed) 
column contains anything other than NULL, there is no crash.

Test Script:

$sql = 'SELECT NULL';

$c = odbc_connect('Driver=SQL Server Native Client 
11.0;server=hpesc1;uid=xxx;pwd=xxx;Database=xxx','','');

$e = odbc_exec($c, $sql);

$row = odbc_fetch_array($e);


Here are different combinations of SQL that will or won't crash PHP:

$sql = 'SELECT NULL'; // PHP SEGFAULT
$sql = 'SELECT NULL as [one]'; // OK
$sql = 'SELECT 1'; // OK
$sql = 'SELECT 1, NULL'; // SEGFAULT
$sql = 'SELECT 1, NULL as [two]'; // OK

And a backtrace:


#0  zend_inline_hash_func (nKeyLength=<optimized out>, arKey=0x0) at 
/usr/src/php-5.3.16/Zend/zend_hash.h:283
#1  _zend_hash_add_or_update (ht=0xfce8b8, arKey=0x0, nKeyLength=1, 
pData=0x7fffffffab90, nDataSize=8, pDest=0x0, flag=1) at /usr/src/php-
5.3.16/Zend/zend_hash.c:218
#2  0x000000000057528f in php_odbc_fetch_hash (ht=<optimized out>, 
return_value=0xfccfe8, result_type=2, return_value_ptr=<optimized out>, 
this_ptr=<optimized out>, 
    return_value_used=<optimized out>) at /usr/src/php-
5.3.16/ext/odbc/php_odbc.c:1775


My comprehension of C & the PHP source code is very limited, but it looks like 
php_odbc.c lines 1752 (handling of SQL_NULL_DATA) and 1771 through 1779 are 
suspect.  I think php_odbc.c may be using zend_hash_update improperly but I 
can't tell for sure.

And finally, here is a workaround script that DOES NOT segfault:


<?php


$c = odbc_connect('Driver=SQL Server Native Client 
11.0;server=hpesc1;uid=xxx;pwd=xxx;Database=xxx','','');

$e = odbc_exec($c, 'SELECT NULL');

$true = odbc_fetch_row($e);

$row = odbc_result($e, 1);

var_dump($row); // "NULL" -- no segfault

This problem is isolated to the SQL Server Native Client ODBC Driver. Most other 
ODBC drivers will automatically provide some type of aliased column name for 
arbitrary values that you select.

When using a SELECT 'VALUE' statement with SQL Server ODBC, the 
php_odbc_fetch_hash() function returns the column as 'VALUE' => 'VALUE' -- that 
is, the value you select is also the key in the array.

The problem occurs at the end of the php_odbc_fetch_hash() function in 
php_odbc.c (for me, on 5.2.17 it begins on line 1510) and it looks like this:

if (!*(result->values[i].name)) { // GDB says this evaluates to 1
  zend_hash_update(Z_ARRVAL_P(return_value), Z_STRVAL_P(tmp),
    Z_STRLEN_P(tmp)+1, &tmp, sizeof(zval *), NULL); // SEGFAULT

This usage of zend_hash_update() causes a segfault in PHP 5.2.17 and PHP 5.3.16.  
I guess that result->values[i].name looks legit and/or usable when it is not.

I updated the if statement to read:

if (!*(result->values[i].name) && Z_TYPE_P(tmp) != IS_NULL) { // Evaluates false 
for SQL NULLs that sets ZVAL_NULL(tmp)

This skips the incorrect usage of zend_hash_update with Z_STR* functions and 
proceeds to the "else" condition that handles it correctly.

For us, this solution works perfectly and the end-result is array("" => NULL) 
instead of a segfault.  Other unaliased NULL values from other databases 
continue to work the same way as before (iSeries ODBC drivers return 
array("0001" => NULL))

Here's the rub:  I have no idea how to generate or submit a patch.  But this fix 
works.  If someone can turn this into a real fix and run with it, great.  If 
someone would contact me and help me turn it into a real patch, I would be happy 
to help.

ssb, are you still active for odbc bugs fix?

Here's a fix for this issue: https://github.com/php/php-src/pull/193

Please accept it! Would be nice to have a fix before the next 5.5 beta.