|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #54007 odbc seg faults with null data returned from DB2
Submitted: 2011-02-13 16:23 UTC Modified: 2020-10-18 04:22 UTC
Avg. Score:4.5 ± 1.0
Reproduced:21 of 21 (100.0%)
Same Version:4 (19.0%)
Same OS:12 (57.1%)
From: ken at focusschoolsoftware dot com Assigned: cmb (profile)
Status: No Feedback Package: ODBC related
PHP Version: 5.3.5 OS: Linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2011-02-13 16:23 UTC] ken at focusschoolsoftware dot com
This bug happens in many of the odbc functions that handle results from a query, 
but I'll point out one example:

The default case in php_odbc.c:
if (result->values[field_ind].vallen == SQL_NULL_DATA) {
} else {
     RETURN_STRINGL(result->values[field_ind].value, result-
>values[field_ind].vallen, 1);

result->values[field_ind].vallen seems to be corrupted when fetching NULL data 
on a 64-bit system.  Since it does not equal 
SQL_NULL_DATA, the else clause is executed causing a seg fault because it is 
trying to handle a NULL case.

Test script:
I have no test script to show, because the only as400/db2 server I have access to is behind a VPN at the moemnt.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-02-13 18:05 UTC]
-Status: Open +Status: Feedback
 [2011-02-13 18:05 UTC]
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 for *NIX and 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.

 [2011-02-13 19:05 UTC] ken at focusschoolsoftware dot com
-Status: Feedback +Status: Open
 [2011-02-13 19:05 UTC] ken at focusschoolsoftware dot com
#0  0x00007ffff6879ea1 in memcpy () from /lib/
#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>, 
    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
 [2011-02-13 19:07 UTC] ken at focusschoolsoftware dot com
php_odbc.c:2158 -> RETURN_STRINGL(result->values[field_ind].value, result-
>values[field_ind].vallen, 1);
 [2011-07-22 15:19 UTC] 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.

 [2011-11-10 09:38 UTC] 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);

it don't crash but give:

  <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...
 [2012-10-19 12:16 UTC] 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.
 [2013-04-08 14:34 UTC] 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
 [2020-10-06 14:50 UTC]
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2020-10-06 14:50 UTC]
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.
 [2020-10-18 04:22 UTC] php-bugs at lists dot php dot net
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.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 12 15:01:30 2024 UTC