|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #70123 OOM on odbc_exec against DB2
Submitted: 2015-07-24 00:01 UTC Modified: 2015-07-28 19:38 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: twist at fowlie dot net Assigned: cmb (profile)
Status: Duplicate Package: ODBC related
PHP Version: 5.6.11 OS: Ubuntu 14.04.2 x64
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: twist at fowlie dot net
New email:
PHP Version: OS:


 [2015-07-24 00:01 UTC] twist at fowlie dot net
When running 5.6.11 with unix_odbc (2.2.14p2) and the iSeriesAccess (6.1.0-2.2) drivers, I received an OOM where PHP tries to allocate an enormous amount of memory for a very simple query.

Once it hits odbc_exec() it throws the fatal error.

The same configuration and script runs on 5.3.2 as expected.

Unfortunately, I don't know my way around the source to suggest a fix as the developer in Bug #69354 did. I'm comfortable applying patches and running things through make with some guidance.

My php.ini is stock Ubuntu.

Test script:
$dbh = odbc_connect("LMS", user, pass);
$query = "select * from CNFNAR where NCNARR like '%JDF%'";
$res = odbc_exec($dbh, $query);

Actual result:
PHP Fatal error:  Out of memory (allocated 262144) (tried to allocate 14944499140640374786 bytes) on line 2


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-07-24 12:10 UTC]
Please try with PHP 5.6.12RC1[1] where the possibly related bug
#69975 has been fixed. If the issue is not solved with this
version, please provide the table definition of CNFNAR and an ODBC
trace[2] of the test script. Please do not embed a huge ODBC trace
directly in the bug report, but rather put it somewhere else
(pastebin, gist.github etc.) and link to it.
 [2015-07-24 12:38 UTC]
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2015-07-24 12:38 UTC]
Forgot the footnotes:

[1] <>
[2] <>
 [2015-07-24 21:51 UTC] twist at fowlie dot net
-Status: Feedback +Status: Assigned
 [2015-07-24 21:51 UTC] twist at fowlie dot net
I thought I should just respond, even though I haven't made much progress. I've downloaded 5.6.12RC1 and have spent the morning trying to get it installed, but haven't made much progress generally. I had forgotten how much fun in can be to configure/make/make install -- needless to say, it's taking me a while. Even though I've compiled it with unixODBC, I can't find the module, let alone get it installed. I'll continue to try over the weekend.

Thanks for pointing me to #69975. I agree that it sounds like the two are closely related.

 [2015-07-24 22:21 UTC]
Before you spend too much time trying to build PHP 5.6.12RC1,
please consider to get an ODBC trace with 5.6.11 and post the
table definition. This is likely to show already whether the patch
would possibly fix your issue, too. :)
 [2015-07-28 17:23 UTC] twist at fowlie dot net
OK... I *finally* got it compiled and configured properly. I can't believe how much I've forgotten over the years -- I'm definitely too spoiled by distro packages!

Everything is working correctly with 5.6.12RC1, so I presume that the fix for #69975 fixes this one as well. Do I mark this one closed?

Thanks for your kind assistance, Christoph!

 [2015-07-28 19:38 UTC]
-Status: Assigned +Status: Duplicate
 [2015-07-28 19:38 UTC]
Thanks for checking 5.6.12RC1, James. So I'm marking this bug as
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Tue Jun 15 11:01:24 2021 UTC