Bug #42765 [Opn]: PDO ODBC: Long binary field in query result crashes PHP ("Out of memory" error)

Edit report at https://bugs.php.net/bug.php?id=42765&edit=1 ID: 42765 Updated by: adambaratz@php.net 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: I'm trying to reproduce this. Could you confirm some details so I can make sure I'm changing the right thing? cmb's notes about initializing a value to 0 relate to a different function. This report is for a few versions of PHP 5.x, but odbc_stmt_describe looks largely the same between the PHP-5.6 branch and master. I'm testing with master on Debian 8. I tried both the FreeTDS and the MS ODBC drivers, connecting to SQL Server 2016. I tried this simple script: <?php $pdo = new PDO(...); $stmt = $pdo->query("select cast(1 as varbinary(max)) as col"); var_dump($stmt->fetchAll()); I didn't get an error with either driver. Previous Comments: ------------------------------------------------------------------------ [2016-12-12 17:49:32] amistry at am-productions dot biz cmb, any update on getting this committed? ------------------------------------------------------------------------ [2016-11-02 18:28:08] cmb@php.net Thanks for the patch, Anish! Haven't tested it yet, but it looks good to me. ------------------------------------------------------------------------ [2016-09-21 17:48:07] 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-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> ------------------------------------------------------------------------ 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