Edit report at https://bugs.php.net/bug.php?id=42765&edit=1
ID: 42765
Comment by: amistry at am-productions dot biz
Reported by: sms at inbox dot ru
Summary: PDO ODBC: Long binary field in query result crashes
PHP ("Out of memory" error)
Status: Open
Type: Bug
Package: PDO ODBC
Operating System: Windows 2000 SP4
PHP Version: 5.2.4
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2016-09-21 15:16:42] 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];
RETCODE rc;
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,
------------------------------------------------------------------------
[2015-06-05 20:43:29] cmb@php.net
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] <https://github.com/php/php-src/blob/php-5.6.9/ext/pdo_odbc/odbc_stmt.c#L568-L578>
[2] <https://msdn.microsoft.com/en-us/library/ms713558(v=vs.85).aspx>
[3] <https://msdn.microsoft.com/en-us/library/ms713974(v=vs.85).aspx>
------------------------------------------------------------------------
[2015-06-05 17:37:54] cmb@php.net
> 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?):
<https://msdn.microsoft.com/en-us/sqlserver/ff657782.aspx>.
------------------------------------------------------------------------
[2014-10-06 15:58:19] 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.
------------------------------------------------------------------------
[2011-08-30 13:07:12] 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 :(
------------------------------------------------------------------------
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=42765
--
Edit this bug report at https://bugs.php.net/bug.php?id=42765&edit=1