Bug #54007 [Fbk->NoF]: odbc seg faults with null data returned from DB2

Edit report at https://bugs.php.net/bug.php?id=54007&edit=1 ID: 54007 Updated by: php-bugs@lists.php.net Reported by: ken at focusschoolsoftware dot com Summary: odbc seg faults with null data returned from DB2 -Status: Feedback +Status: No Feedback Type: Bug Package: ODBC related Operating System: Linux PHP Version: 5.3.5 Assigned To: cmb Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2020-10-06 14:50:33] cmb@php.net 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. ------------------------------------------------------------------------ [2013-04-08 14:34:05] brandonkirsch at gmail dot com 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 ------------------------------------------------------------------------ [2012-10-19 12:16:09] tuomas dot angervuori at gmail dot com 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. ------------------------------------------------------------------------ [2011-11-10 09:38:10] giuseppe at blandino dot it 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... ------------------------------------------------------------------------ [2011-07-22 15:19:53] hborrel at gmail dot com 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), '') ------------------------------------------------------------------------ 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=54007 -- Edit this bug report at https://bugs.php.net/bug.php?id=54007&edit=1