|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #66318 PDO_Informix doesn't handle closed persistent connections
Submitted: 2013-12-18 14:39 UTC Modified: 2016-02-07 15:45 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: andreas dot streichardt at 100days dot de Assigned: vnkbabu (profile)
Status: Assigned Package: PDO_INFORMIX (PECL)
PHP Version: Irrelevant OS: openSuSE 12.2
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.
Block user comment
Status: Assign to:
Bug Type:
From: andreas dot streichardt at 100days dot de
New email:
PHP Version: OS:


 [2013-12-18 14:39 UTC] andreas dot streichardt at 100days dot de
The informix PDO extension supports the PDO persistent attribute. However it seems to only save the handle and will never check if it is still valid. Whenever the connection was closed (for example database server was shut down, timeouts or whatever) the (apache in this case) process is messed up and won't be able to handle any new informix connection to that dsn.

Executing any query on that broken connection will simply return false.

Test script:
$start = microtime(true);
$options = [];
$options[PDO::ATTR_PERSISTENT] = true;
$connection = new PDO('informix:host=ifxservdev;service=sqlexec;database=develop11;server=ifxsrv;protocol=onsoctcp;EnableScrollableCursors=1;DB_LOCALE=de_DE.cp1252;CLIENT_LOCALE=de_DE.utf8', 'develop', 'develop', $options);

var_dump(microtime(true) - $start);
$stmt = $connection->query("SELECT kd_nr, kd_ans1 FROM kunden");

var_dump(gettype($stmt), getmypid(), $connection->errorInfo());

Expected result:
float(1.5020370483398E-5) string(6) "object" int(27040) array(3) { [0]=> string(5) "00000" [1]=> int(0) [2]=> string(24) " ((null)[0] at (null):0)" }

Actual result:
float(1.5020370483398E-5) string(6) "object" int(27050) array(3) { [0]=> string(5) "00000" [1]=> int(0) [2]=> string(24) " ((null)[0] at (null):0)" }

(then restart database server)

float(1.4066696166992E-5) string(7) "boolean" int(27050) array(3) { [0]=> string(5) "08S01" [1]=> int(-11020) [2]=> string(129) "[Informix][Informix ODBC Driver]Communication link failure. (SQLPrepare[-11020] at /opt/PDO_INFORMIX-1.3.0/informix_driver.c:131)" }


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-12-18 14:41 UTC] andreas dot streichardt at 100days dot de
-Package: PDO related +Package: PDO_INFORMIX
 [2013-12-18 14:41 UTC] andreas dot streichardt at 100days dot de
wrong package :S
 [2014-01-20 12:03 UTC]
-Assigned To: +Assigned To: rahulpriyadarshi
 [2014-01-20 12:03 UTC]
Thank you for reporting this issue, I am able to reproduce this issue.

I saw that connection alive check is not implemented inside the PDO_INFORMIX, I tried to implement this missing part but found only SQL_ATTR_CONNECTION_DEAD connection attribute is available in CSDK to check connection is alive or not, but it doesn't work when connection drop initiated from the server side.

So implementation with SQL_ATTR_CONNECTION_DEAD will not resolve your issue, If you have INFORMIX license then please open a PMR to get it resolve.
 [2014-01-20 17:19 UTC] gaylord at 100days dot de
"implementation with SQL_ATTR_CONNECTION_DEAD will not resolve your issue"

True. The client might not register a connection-close by the server. But how about this:
If the driver tries to make a query and gets the "connection closed" error, it could try to re-connect and then make the query again.

This way, you dont need to rely on the client to detect connection-abort.
AFAIK other drivers do it the same way.
 [2014-01-20 17:23 UTC] andreas dot streichardt at 100days dot de
In fact our customer does have a license and we opened a ticket concerning the issues i reported recently. However the response was quite unsatisfying: They are saying that the PDO_Informix driver is not an IBM product and that it is maintained by the community. Therefore they are not willing to help.

As far as i understand you are an IBM employee. It seems we have just entered an infinite enterprise loop :S

Our PMR number is: PMR-35983,033,724

We will try to push this issue forward from our side so you get the necessary support. Maybe you could ask them as well?
 [2014-01-20 19:15 UTC]
If the driver tries to make a query and gets the "connection closed" error, it could try to re-connect and then make the query again.
Yes, It could be the workaround but not a good solution. 
It would be better to have a CSDK support to check active connection in optimize way.

They are saying that the PDO_Informix driver is not an IBM product and that it is maintained by the community.
I am sorry for this type of response, since IBM do provide support for PDO_INFORMIX.

Please try to push this issue, I will also try from my side.
 [2014-02-08 15:20 UTC]
I am going to implement the workaround through making a query.

I saw the PMR you have opened, you have reported many issue there, could you please remove other issues from the PMR. I will resolve those issues and provide you the patch from this bug tracking system.
 [2014-02-11 10:09 UTC]
I have made a patch for this issue, and uploaded the changes to svn branch.

Could you please give a try to the latest code available at the SVN and let me know it works for you.
 [2014-02-17 09:55 UTC] andreas dot streichardt at 100days dot de
Segfault when doing second request:

vmdevelop:/home/develop # gdb /usr/local/apache2/bin/httpd
GNU gdb (GDB) SUSE (7.5.1-2.5.1)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-suse-linux".
For bug reporting instructions, please see:
Reading symbols from /usr/local/apache2/bin/httpd...done.
(gdb) run -X -d /usr/local/apache2
Starting program: /usr/local/apache2/bin/httpd -X -d /usr/local/apache2
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/".
Warning: DocumentRoot [/home/develop/Dokumente/workspace/topconew2/web] does not exist

Program received signal SIGSEGV, Segmentation fault.
0xb53bd39a in _OdbcValidateHandle () from /usr/lib/informix/lib/cli/
Missing separate debuginfos, use: zypper install cyrus-sasl-debuginfo-2.1.25-21.2.1.i586 glibc-debuginfo-2.15-22.17.1.i686 krb5-debuginfo-1.10.2-3.12.1.i586 libbz2-1-debuginfo-1.0.6-20.1.7.i586 libcom_err2-debuginfo-1.42.4-2.1.2.i586 libcurl4-debuginfo-7.25.0-2.1.2.i586 libgcc47-debuginfo-4.7.1_20120723-1.1.1.i586 libicu49-debuginfo-49.1-2.1.2.i586 libidn-debuginfo-1.25-2.1.2.i586 libkeyutils1-debuginfo-1.5.3-7.1.2.i586 libldap-2_4-2-debuginfo-2.4.31-2.1.3.i586 liblzma5-debuginfo-5.0.3-12.2.2.i586 libopenssl1_0_0-debuginfo-1.0.1e-2.8.1.i586 libselinux1-debuginfo-2.0.91-19.1.15.i586 libssh2-1-debuginfo-1.4.0-4.1.2.i586 libstdc++47-debuginfo-4.7.1_20120723-1.1.1.i586 libxml2-2-debuginfo-2.7.8+git20120223-8.18.1.i586 zlib-debuginfo-1.2.7-2.1.2.i586
(gdb) bt
#0  0xb53bd39a in _OdbcValidateHandle () from /usr/lib/informix/lib/cli/
#1  0xb53b12ab in __SQLPrepare () from /usr/lib/informix/lib/cli/
#2  0xb53b152a in SQLPrepare () from /usr/lib/informix/lib/cli/
#3  0xb54e3445 in informix_handle_check_liveness (dbh=0x830c198) at /home/develop/pdo_informix/informix_driver.c:558
#4  0xb75f4c77 in zim_PDO_dbh_constructor (ht=4, return_value=0xb5675c50, return_value_ptr=0x0, this_ptr=0xb5675b30, return_value_used=0)
    at /home/develop/php-5.4.4/ext/pdo/pdo_dbh.c:307

Script is:

    $start = microtime(true);
    $options = [];
    $options[PDO::ATTR_PERSISTENT] = true;
    $connection = new PDO('informix:host=ifxservdev;service=sqlexec;database=develop11;server=ifxsrv;protocol=onsoctcp;EnableScrollableCursors=1;DB_LOCALE=de_DE.cp1252;CLIENT_LOCALE=de_DE.cp1252', 'develop', 'develop', $options);
    var_dump(microtime(true) - $start);

    //var_dump(microtime(true) - $start);
    $stmt = $connection->query("SELECT * FROM teilestamm");
    foreach ($stmt as $row) {
//        var_dump($row);
    $connection = null;
 [2014-02-20 10:05 UTC]
I am not able to reproduce the segmentation fault.
Could you let us know which apache you are using multi-threaded or multi-process(pre-forked)? 

It is always recommended to use pre-forked apache, so if you are using multi-threaded apache then please switch to the pre-forked one.
 [2014-02-20 11:41 UTC]
I have made a small changes(committed in SVN branch) in the implementation of check for liveness of persistent connection, you can give a try to this. 

But if you are using multi-threaded apache then please switch to the multi-process apache.
 [2014-02-20 15:49 UTC] rolf dot maassen at toyota-tis dot de
We can still reproduce this issue, using latest Version of PDO Informix (svn revision 332869). We also tried with latest PHP Version 5.4.25. Apache is:
Server version: Apache/2.2.22 (Unix)
Server built:   Nov 23 2012 17:12:23
Server's Module Magic Number: 20051115:30
Server loaded:  APR 1.4.5, APR-Util 1.4.1
Compiled using: APR 1.4.5, APR-Util 1.4.1
Architecture:   32-bit
Server MPM:     Prefork
  threaded:     no
    forked:     yes (variable process count)

We noticed that using your latest changes the additional issue we send you through the PMR (the non minimal testcase indicating a memory leak) is now crashing with a segmentation fault so maybe this version might even help you finding the memory leak.

Interestingly the memleak test will only segfault when executed by a non super user:

develop@vmdevelop:~/tmp/memleak> php test.php
develop@vmdevelop:~/tmp/memleak> php test.php
develop@vmdevelop:~/tmp/memleak> su
vmdevelop:/home/develop/tmp/memleak # php test.php
vmdevelop:/home/develop/tmp/memleak # php test.php
 [2014-02-24 13:27 UTC]
I am now able to reproduce the segfault, and fixed the same. This is now working fine in my environment. I have committed the changes into SVN branch, please give a try to this and let me know how it works in your environment.

The test case you have given for memory leak issue have dependencies upon other scripts which is not present in that. So, please send the test case which I can run to reproduce the memory leak issue.
 [2014-03-13 12:04 UTC]
Segmentation fault with persistent connection when doing the 2nd persistent call is the bug with PHP-5.4.7, It has been reported and resolved by the bug
 [2016-02-07 15:45 UTC]
-Assigned To: rahulpriyadarshi +Assigned To: vnkbabu
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Mon Jun 24 19:01:25 2019 UTC