Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Backtrace:
#0  0x00007ffff6879ea1 in memcpy () from /lib/libc.so.6
#1  0x00000000006af648 in _estrndup (s=0x7ffff57cd4b8 "", 
    length=<value optimized out>) at /usr/include/bits/string3.h:52
#2  0x00007ffff5edadcb in zif_odbc_result (ht=<value optimized out>, 
    return_value=0x7ffff57d6940, return_value_ptr=<value optimized out>, 
    this_ptr=<value optimized out>, return_value_used=<value optimized out>, 
    tsrm_ls=0xc91090)
    at /home/focus/Development/php-5.3.5/ext/odbc/php_odbc.c:2158
#3  0x000000000072730d in zend_do_fcall_common_helper_SPEC (
    execute_data=0x7ffff7ed39a0, tsrm_ls=0xc91090)
    at /home/focus/Development/php-5.3.5/Zend/zend_vm_execute.h:316
#4  0x00000000006f927b in execute (op_array=0xeeb010, tsrm_ls=0xc91090)
    at /home/focus/Development/php-5.3.5/Zend/zend_vm_execute.h:107
#5  0x00000000006cec48 in zend_execute_scripts (type=<value optimized out>, 
    tsrm_ls=0xc91090, retval=<value optimized out>, file_count=3)
    at /home/focus/Development/php-5.3.5/Zend/zend.c:1194
#6  0x0000000000670e2d in php_execute_script (
    primary_file=<value optimized out>, tsrm_ls=<value optimized out>)
    at /home/focus/Development/php-5.3.5/main/main.c:2265
#7  0x0000000000767abe in main (argc=<value optimized out>, 
    argv=<value optimized out>)
    at /home/focus/Development/php-5.3.5/sapi/cli/php_cli.c:1193

FYI:
php_odbc.c:2158 -> RETURN_STRINGL(result->values[field_ind].value, result-
>values[field_ind].vallen, 1);

We have the same problem.

As a work around we've had to add this to any feild that may return a NULL.

COALESCE(CHAR(DELIVERYDATE), '')

I've the same problem.
I'm trying to migrate my web applications from an old Ubuntu server 64bit with PHP 5.2.4 and DB2 9.1.0 to a new Ubuntu 10.4 LTS 64 bit server with PHP Version 5.3.2-1ubuntu4.10, Apache/2.2.14 and DB2 ver. 9.7.4.
This is a sample of code:

  $sql = "SELECT field FROM table WHERE ...";
  $result = odbc_exec($id_connect, $sql);
  if (odbc_fetch_row($result)) {
      $field = (int) odbc_result($result,"field");
               // seg fault when field is null                               
  }

But if I try this:

  $sql = "SELECT field FROM table WHERE ...";
  $result = odbc_exec($id_connect, $sql);
  odbc_result_all($result);

it don't crash but give:

  <table><tr><th>FIELD</th></tr>
  <tr><td>
vÖN ’\UJõÕseõº\ŠŒ+ŽT9</td></tr></table>

It seems that when field is null the ODBC driver return the pointer of somewhere in the memory...

Seems that this bug is somehow 64bit related. I get segmentation fault on my 
64bit ubuntu 12.04 (php-5.3.10 & IBM i Access 7.1) but not with 32bit Debian 
(php-5.3.3 & IBM i Access 7.1).

I can do more tests & provide more detailed information if needed.

Hi friends,

I have a fix for this problem, which is caused by some rich history in the written standard for ODBC.  IBM's "64-bit" ODBC drivers are written against an older specification, and they are affected by changes in the size of SQLLEN / SQLULEN types as the specification has evolved.

The "correct" solution for this problem is for IBM to release iSeriesAccess ODBC drivers that fit the modern specification for 64-bit ODBC.

A workaround that we successfully used in production for several years includes casting certain 64-bit ODBC values down to 32-bits when comparing for SQL_NULL_DATA. It essentially changes PHP to conform to an outdated ODBC spec that IBM requires. It doesn't break other "real" 64-bit ODBC drivers as long as you aren't pulling back individual values > 4GB.

I'll re-iterate that PHP is using the correct specification for 64-bit ODBC, so this is *NOT* a bug. But if you need compatibility with IBM in a 64-bit environment, you can have / study / re-use the workaround I developed and posted at http://perceptionilluminates.com/php/php_odbc.c

Is this still an issue, or can we assume that these broken drivers
have been fixed in the meantime?

If not, I wonder whether it wouldn't be cleaner to initialize the
output parameter with zero, instead of casting to int afterwards.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.