I am working on a fix for pdo_odbc to bring it up to ODBC 3.51 API 
specification including full 64bit support, similar to the work i did on 
the regular ext/odbc code.

iodbc: What is the status with this fix? (if this still isn't fixed, 
please update the PHP version..)

I believe we have a same/similar situation running PHP 5.2.9 on 64-bit SLES10 - with the ibm-db2 1.8.2 pdo_odbc extension. Getting a "Child pid nnn exit signal Segmentation fault (11)". Here is a simple recreate script trying to connect to the DB2 "SAMPLE" database:

<?php
 $dbconn = new PDO('odbc:SAMPLE','db2inst1','pw'); /* pw not actual pw */
?>

Program terminated with signal 11, Segmentation fault.
#0  _zval_ptr_dtor (zval_ptr=0x3fffff31c70)
    at /opt/SFI/php-5.2.9/Zend/zend_execute_API.c:412
412             (*zval_ptr)->refcount--;

Backtrace:
#0  _zval_ptr_dtor (zval_ptr=0x3fffff31c70)
    at /opt/SFI/php-5.2.9/Zend/zend_execute_API.c:412
#1  0x0000020000a36282 in zend_do_fcall_common_helper_SPEC (
    execute_data=0x3fffff31ec0) at /opt/SFI/php-5.2.9/Zend/zend_execute.h:155
#2  0x0000020000a26992 in execute (op_array=0x20002bb0d90)
    at /opt/SFI/php-5.2.9/Zend/zend_vm_execute.h:92
#3  0x0000020000a032ac in zend_execute_scripts (type=<value optimized out>,
    retval=0x0, file_count=2) at /opt/SFI/php-5.2.9/Zend/zend.c:1134
#4  0x00000200009ba4c4 in php_execute_script (primary_file=0x3fffff344d0)
    at /opt/SFI/php-5.2.9/main/main.c:2023
#5  0x0000020000a970c8 in php_handler (r=0x2aaaade5ba8)
    at /opt/SFI/php-5.2.9/sapi/apache2handler/sapi_apache2.c:632
#6  0x000002aaaaaedce0 in ap_run_handler () from /usr/sbin/httpd2-prefork
#7  0x000002aaaaaf1516 in ap_invoke_handler () from /usr/sbin/httpd2-prefork
#8  0x000002aaaaafccd8 in ap_process_request () from /usr/sbin/httpd2-prefork
#9  0x000002aaaaafa08c in ?? () from /usr/sbin/httpd2-prefork
#10 0x000002aaaaaf55b4 in ap_run_process_connection ()
   from /usr/sbin/httpd2-prefork
#11 0x000002aaaab01190 in ?? () from /usr/sbin/httpd2-prefork
#12 0x000002aaaab014b0 in ?? () from /usr/sbin/httpd2-prefork
#13 0x000002aaaab0158a in ?? () from /usr/sbin/httpd2-prefork
#14 0x000002aaaab021d4 in ap_mpm_run () from /usr/sbin/httpd2-prefork
#15 0x000002aaaaad8646 in main () from /usr/sbin/httpd2-prefork

Please let me know if this falls within the known exposure of the work being done on this bug. And a status?

Thanks.

Was able to circumvent by configuring (now, PHP 5.2.10) with --enable-debug.  PHP 5.2.10 without --enable-debug fails the same way as did 5.2.9.  Can someone advise if this is the same problem and a prognosis for correction?

I am very familiar with this problem - IT IS NOT A BUG IN PHP.

64-bit IBM iSeriesAccess ODBC drivers are built against an antiquated definition of what 64-bit ODBC should be. Instead, the IBM drivers use 32-bit values in places where 64-bits should be used.

The end result is that a 32-bit value ("-1" to represent NULL) is interpreted by 64-bit PHP as a large number, causing it to read an invalid memory address and therefore segfault.

You can ask IBM for a better ODBC driver, but they ignored us when we tried.

I have a custom patch for php_odbc.c that "fixes" the problem by hacking up PHP ODBC bindings to treat all ODBC SQL_NULL_DATA values as 32-bit. There are small potential downsides that can occur if you use this patch with a real 64-bit ODBC driver AND you try to access fields > 4GB.

http://www.perceptionilluminates.com/php/php_odbc.c -- It's antiquated (PHP 5.2.17) but it is also well commented, so you can port the hack to a modern version if you'd like.

This seems to be a duplicate of bug 50444, which has been fixed.

As to Brandon's comment about this being a problem with the IBM i Access ODBC driver, that is not the case here. First of all, this issue is for pdo_odbc which is completely different than php-odbc. The problem he describes is caused by the old iSeries Access for Linux 7.1 ODBC driver not using 64-bit SQLLEN values. Since php-odbc was updated to use 64-bit SQLLEN values, this caused an incompatibility with the iSeries Access driver.

However, this is not the case anymore, since the new IBM i Access Client Solutions ODBC driver is now fully 64-bit compatible. In fact, the problem in this issue issue is directly related to that, since it is in fact pdo_odbc which is not fully 64-bit compatible. These drivers were first released in June 2103 and are available through IBM Entitled Software Support. I'd urge anyone using iSeries Access for Linux 7.1 or below to update to these drivers (and if using pdo_odbc, make sure you have a release that includes the fix in bug 50444).

Oh, and to be clear - this problem with pdo_odbc is not restricted to the IBM i Access ODBC driver, but any fully 64-bit driver (which is pretty much all of them, especially the open source ones). In fact, it's unclear to me whether the submitter was even using the iSeries Access ODBC driver, but more likely the DB2 LUW CLI driver.

Thanks, marked duplicate of bug #50444.