|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #42765 PDO ODBC: Long binary field in query result crashes PHP ("Out of memory" error)
Submitted: 2007-09-26 11:00 UTC Modified: 2016-11-02 18:28 UTC
Avg. Score:4.9 ± 0.3
Reproduced:23 of 23 (100.0%)
Same Version:4 (17.4%)
Same OS:5 (21.7%)
From: sms at inbox dot ru Assigned: cmb
Status: Assigned Package: PDO ODBC
PHP Version: 5.2.4 OS: Windows 2000 SP4
Private report: No CVE-ID:
Have you experienced this issue?
Rate the importance of this bug to you:

 [2007-09-26 11:00 UTC] sms at inbox dot ru
With PDO ODBC I can't get long binary data from Microsoft SQL Server (image and varbinary(MAX) fields). PDO->query, PDOStatement->execute() always result in PHP "Out of memory" error, even if output contains no rows.
The same queries work fine with ODBC unified extension.

Reproduce code:
$dbh=new PDO('odbc:Driver={SQL Server};Server=localhost;Database=test','user','pass');
$dbh->query("select [nbin] from [atts] where [id]=1");

Expected result:
No PHP fatal errors

Actual result:
PHP Fatal error:  Out of memory (allocated 262144) (tried to allocate 4294967295 bytes) in D:\Web\test.php on line 3


patch-blob-uninitialized-odbc_stmt.c (last revision 2016-09-21 15:26 UTC) by amistry at am-productions dot biz)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2007-09-27 18:07 UTC] carlton dot whitehead at cebesius dot com
I encountered this bug with this setup:
Windows Server 2003 SP2 32bit
PHP 5.2.4
MS SQL Server 2005 Express SP2

PDO ODBC reproduce code:
// lobtestPdoOdbc.php
    $db = new PDO('odbc:fmarchive_mssql', 'change', 'me');
    $stp = 'SELECT attdata FROM fm_faxin_att WHERE id = 119085913400004
AND attid = 0'; // statement to prepare
    $ps = $db->prepare($stp);
    $execResult = $ps->execute();
    var_export($execResult, true);
catch (PDOException $e)

Expected result:
output to browser: true

Actual result:
*Fatal error*: Out of memory (allocated 262144) (tried to allocate
4294967295 bytes) in *C:\Inetpub\wwwroot\FMarchive\lobtestPdoOdbc.php*
on line *9*

plain ODBC reproduce code:
// lobtestOdbc.php
$res = odbc_connect('fmarchive_mssql', 'change', 'me');
if (!$res) { die ('failed to connect'); }

$stp = 'SELECT attdata FROM fm_faxin_att WHERE id = 119085913400004 AND attid = 0'; // statement to prepare
$ps = odbc_prepare($res, $stp);
if (!$res) { die ('failed to prepare statement'); }

$execResult = odbc_execute($ps);
echo var_export($execResult, true);

Expected result:
output to browser: true

Actual result:
output to browser: true
(this indicates odbc_execute worked correctly)
 [2008-06-10 09:06 UTC] csa at dside dot dyndns dot org
I got the same problem on Linux (64bit, php 5.2.6). Actually, the problem is existing in all configurations. I have take a brief look through php sources. The bug is in pdo_odbc code and affects all architectures and underlying database engines.

Actually it is in 'ext/pdo_odbc/odbc_stmt.c', function 'odbc_stmt_describe'. The 'displaysize' variable is expected to contain  estimated size of the column. This could be a negative number if BLOB or TEXT data is stored (since the record sizes could seriously vary). However, later in this function the check on data size does not consider negative numbers. This causes the described behavior. This patch solves problem for me:

A Linux user trying to access MSSQL over FreeTDS may be interested in the following patches as well:
 [2008-06-10 09:08 UTC] csa at dside dot dyndns dot org
By the way feel free to contact me on if you have problems with this patches.
 [2008-10-03 15:34 UTC] jeffreybolle at gmail dot com
I had the same problem recently. I'd like to thank csa for the great source code patch.  Recompiling the source under windows wasn't easy and it took me many hours to piece together all the software and libraries required.  The result was a fixed extension that can access large blob files, this has been tested under Windows Vista 32bit.
I thought I'd post a link for the compiled extension (PHP 5.2.6) in case any other windows users want to make use of this fix without going through the hassle of learning how to compile PHP from source.

If there are any problems feel free to contact me at

 [2008-10-03 21:41 UTC]
Thanks for the patches and testing.

About compiling php on windows, take a look here:
 [2009-04-25 14:50 UTC]
Please try using this CVS snapshot:
For Windows:

 [2009-04-29 10:44 UTC]
Confirmed not fixed with latest PHP 5.2 snapshot VC6 x86 Thread Safe (2009-Apr-27 00:00:00):

Fatal error: Out of memory (allocated 262144) (tried to allocate 4294967295 bytes)

Current workaround is getting the length of the image, retrieving chunks of 4096 characters and putting them back together in PHP.

SQL-Queries for this workaround look like these:

    SELECT DATALENGTH(imagefield) AS imagelength FROM imagetable WHERE imageid = ?

    SELECT CAST(SUBSTRING(imagefield, offset, length) AS VARCHAR(4096)) AS imagechunk FROM imagetable WHERE imageid = ?

 [2010-06-20 17:43 UTC]
-Status: Assigned +Status: Open -Assigned To: pajoye +Assigned To:
 [2010-06-20 17:43 UTC]
hm, I don't maintain odbc.

However I would suggest SqlServer users on Windows to use SqlSrv instead, much more stable and features complete.
 [2011-08-30 13:07 UTC] andreas at codejungle dot org
Bug is still existing in PHP 5.3.5 (os ubuntu natty)

The chunk workaround from skettler is working, but 22 000 queries for a 40 MB file is not optimal.

I tried also the php-ds-odbc_blob.patch, and the "Out of memory" error was gone,
but for some reasons, now the files are twice as large :(
 [2014-01-01 12:53 UTC]
-Package: PDO related +Package: PDO ODBC
 [2014-10-06 15:58 UTC] joachim dot havloujian at fauser dot ag
I am getting the exact same error when fetching a long binary field from a Microsoft SQL Server.

The problem is that I rely on a PHP extension which supports MSSQL and the latest PHP build. Besides ODBC there are none which are fully working with the newest PHP version. The extension PHP_MSSQL isn't stated as deprecated but there is no official update. SqlSrv, the official driver from Microsoft, does only support PHP up to 5.4 and it looks like there won't be any update in the near future too.

That's why me and my coworkers would appreciate if this bug will be fixed soon.

Best regards.
 [2015-06-05 17:37 UTC]
> SqlSrv, the official driver from Microsoft, does only support
> PHP up to 5.4 and it looks like there won't be any update in the
> near future too.

The drivers are actively maintained (again?):
 [2015-06-05 20:43 UTC]
It appears that csa is right. Unfortunately, the patch isn't
available anymore.

Anyhow, I see two potential problems with the relevant code[1].
The first is that displaysize is not initialized, but the MSDN
documentation[2] states:

| Please note that some drivers may only write the lower 32-bit or
| 16-bit of a buffer and leave the higher-order bit unchanged.
| Therefore, applications should initialize the value to 0 before
| calling this function.

The second is that displaysize (signed) is assigned to colsize
(unsigned). However, the MSDN documentation[3] states:

| If the driver cannot determine the column or parameter length of
| variable types, it returns SQL_NO_TOTAL.

SQL_NO_TOTAL is defined to be -4.

[1] <>
[2] <>
[3] <>
 [2016-09-21 15:16 UTC] amistry at am-productions dot biz
The following fixes the issue for me.

--- odbc_stmt.c.orig	2016-09-21 10:57:45.052396000 -0400
+++ odbc_stmt.c	2016-09-21 11:05:02.584261000 -0400
@@ -551,8 +551,8 @@
 	struct pdo_column_data *col = &stmt->columns[colno];
 	SWORD	colnamelen;
-	SQLULEN	colsize;
-	SQLLEN displaysize;
+	SQLLEN	colsize = 0;
+	SQLLEN displaysize = 0;
 	rc = SQLDescribeCol(S->stmt, colno+1, S->cols[colno].colname,
 			sizeof(S->cols[colno].colname)-1, &colnamelen,
 [2016-09-21 17:48 UTC] amistry at am-productions dot biz
As an update to my last post.  That patch is for php 5.6 or later.  If you're trying make this work with an older version of php (eg. 5.5)  You'll need to also backport the fixes from 5.6 to odbc_stmt.c with regard to SQL_VARCHAR ,etc. before it will function correctly.
 [2016-11-02 18:28 UTC]
-Assigned To: +Assigned To: cmb
 [2016-11-02 18:28 UTC]
Thanks for the patch, Anish! Haven't tested it yet, but it looks good
to me.
 [2016-12-12 17:49 UTC] amistry at am-productions dot biz
cmb, any update on getting this committed?
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Mon Feb 20 22:01:35 2017 UTC