php.net |  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
Votes:22
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
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: ken at focusschoolsoftware dot com
New email:
PHP Version: OS:

 

 [2011-02-13 16:23 UTC] ken at focusschoolsoftware dot com
Description:
------------
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:
default:
if (result->values[field_ind].vallen == SQL_NULL_DATA) {
     RETURN_NULL();
} else {
     RETURN_STRINGL(result->values[field_ind].value, result-
>values[field_ind].vallen, 1);
}
break;

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.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-02-13 18:05 UTC] kalle@php.net
-Status: Open +Status: Feedback
 [2011-02-13 18:05 UTC] kalle@php.net
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.


 [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
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
 [2011-02-13 19:07 UTC] ken at focusschoolsoftware dot com
FYI:
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.

COALESCE(CHAR(DELIVERYDATE), '')
 [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);
  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...
 [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 http://perceptionilluminates.com/php/php_odbc.c
 [2020-10-06 14:50 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2020-10-06 14:50 UTC] 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.
 [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-2020 The PHP Group
All rights reserved.
Last updated: Thu Oct 29 09:02:33 2020 UTC