php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #46473 php segfaults on some queries using pdo_odbc & ibm-db2 on a 64bits platform
Submitted: 2008-11-03 15:35 UTC Modified: 2014-06-04 16:21 UTC
Votes:11
Avg. Score:4.7 ± 0.6
Reproduced:10 of 10 (100.0%)
Same Version:4 (40.0%)
Same OS:2 (20.0%)
From: philippe dot marasse at ac-poitiers dot fr Assigned: iodbc (profile)
Status: Duplicate Package: PDO ODBC
PHP Version: 5.2.6 OS: Linux Red Hat EL5 x86_64
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: philippe dot marasse at ac-poitiers dot fr
New email:
PHP Version: OS:

 

 [2008-11-03 15:35 UTC] philippe dot marasse at ac-poitiers dot fr
Description:
------------
On our both platforms (32 & 64 bits), we have php compiled with support for IBM DB2 database via pdo_odbc extension. We ran into unexpected segfaults deploying a new application on a 64 bits server.

We have tested several client version of DB2 but nothing helped.

At last, it seemed that pdo_odbc extensions did not compile properly, as we got several warnings like :

passing argument 2 of 'SQLRowCount' from incompatible pointer type

Bug #32830 (related to odbc, not pdo_odbc) points out the same issue.

We wrote a little patch that works for us (tm), available at :

http://huan.ac-poitiers.fr/pdo_odbc_db2-x86_64.patch

Rgds.

Reproduce code:
---------------
<?php
  $toto = new PDO("odbc:mydb","user","password");
  $req = "SELECT ETA_DENOMINATION FROM ETABLISSEMENT WHERE ETA_DEPARTEMENT = 16 AND ETA_RNE = '0160001P'";
  $machin = $toto->query($req);
  $truc = $machin->fetchObject();
?>


Expected result:
----------------
nothing indeed :-), it's just a script we used to isolate a query which crashes only on our 64bits servers (of course, it works fine on 32bits platform).

Actual result:
--------------
segfault... unless the value of ETA_DENOMINATION is not NULL.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-11-07 11:45 UTC] iodbc@php.net
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.
 [2009-04-25 15:15 UTC] jani@php.net
iodbc: What is the status with this fix? (if this still isn't fixed, 
please update the PHP version..)
 [2009-06-24 15:57 UTC] d dot stcyr at streamfoundry dot com
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.
 [2009-06-30 19:23 UTC] d dot stcyr at streamfoundry dot com
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?
 [2013-06-26 14:29 UTC] brandonkirsch at gmail dot com
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.
 [2014-01-01 12:52 UTC] felipe@php.net
-Package: PDO related +Package: PDO ODBC
 [2014-06-04 16:18 UTC] kadler at us dot ibm dot com
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.
 [2014-06-04 16:21 UTC] aharvey@php.net
-Status: Assigned +Status: Duplicate
 [2014-06-04 16:21 UTC] aharvey@php.net
Thanks, marked duplicate of bug #50444.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Tue Dec 01 12:02:32 2020 UTC