Bug #54007 [Opn->Fbk]: 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: cmb@php.net
Reported by: ken at focusschoolsoftware dot com
Summary: odbc seg faults with null data returned from DB2
-Status: Open
+Status: Feedback
Type: Bug
Package: ODBC related
Operating System: Linux
PHP Version: 5.3.5
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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), '')
------------------------------------------------------------------------
[2011-02-13 19:07:17] ken at focusschoolsoftware dot com
FYI:
php_odbc.c:2158 -> RETURN_STRINGL(result->values[field_ind].value, result-
>values[field_ind].vallen, 1);
------------------------------------------------------------------------
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
Thread (10 messages)