Edit report at https://bugs.php.net/bug.php?id=69975&edit=1
ID: 69975
Updated by: cmb@php.net
Reported by: jgeert1 at its dot jnj dot com
Summary: PHP is causing Apache to crash when accessing
nvarchar(max) defined columns
-Status: Open
+Status: Verified
Type: Feature/Change Request
Package: ODBC related
Operating System: Windows Server 2012R2
PHP Version: 5.5.26
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
I have now set up a testing environment with SQL Server 2014 and
can reproduce the issue. My patch was way too short-sighted (it
prevents the segfault, but does return empty strings). I'll have
to investigate further.
Previous Comments:
------------------------------------------------------------------------
[2015-07-02 14:24:05] jgeert1 at its dot jnj dot com
Wow that was fast :-)
What do I need to do to get a compiled version for Windows 64-bit?
Thanks.
------------------------------------------------------------------------
[2015-07-02 14:17:11] cmb@php.net
The following patch has been added/updated:
Patch Name: odbc-wvarchar-native-draft
Revision: 1435846631
URL: https://bugs.php.net/patch-display.php?bug=69975&patch=odbc-wvarchar-native-draft&revision=1435846631
------------------------------------------------------------------------
[2015-07-02 14:16:29] cmb@php.net
Thanks for the traces.
At a first glance the problem is that SQLColAttributes()
requesting SQL_COLUMN_DISPLAY_SIZE for column 5 yields 0 for the
Native Driver, but 1073741823 (0x3fffffff) for the SQL Server
driver, whereby the column type is reported as SQL_WVARCHAR (-9)
and SQL_WLONGVARCHAR (-10), respectively. This results in a buffer
of only 1 byte to be emalloc'd()[1], what's likely to cause
problems.
However, I'm confused, because SQL_WVARCHAR is supposed to request
SQL_DESC_OCTET_LENGTH instead of SQL_COLUMN_DISPLAY_SIZE[2]. Maybe
a driver mapping?
Maybe the attached patch "odbc-wvarchar-native-draft" points in
the right direction?
[1] <https://github.com/php/php-src/blob/PHP-5.5.26/ext/odbc/php_odbc.c#L1020>
[2] <https://github.com/php/php-src/blob/PHP-5.5.26/ext/odbc/php_odbc.c#L995>
------------------------------------------------------------------------
[2015-07-02 13:01:18] jgeert1 at its dot jnj dot com
This is the testscript I've used:
$db_datastage = odbc_connect($dsn,$user,$pwd,SQL_CUR_USE_ODBC);
$res = odbc_exec($db_datastage,"select top 10 * from SN.cmdb_ci");
while ($row = odbc_fetch_array($res)) {
var_dump($row);
}
odbc_close($db_datastage);
This trace is the failing one (using "SQL Server Native Client 11.0" as driver):
https://gist.githubusercontent.com/anonymous/757e0f1fabeefbbb1abb/raw/SQLLOG1
This trace is the successful one (using "SQL Server" as driver):
https://gist.githubusercontent.com/anonymous/6d59f9903ca76d43095d/raw/sqllog2
It looks like it's having an issue when fetching the result (2nd result) as it's
displaying:
DIAG [01004] [Microsoft][SQL Server Native Client 11.0]String data, right truncation (0)
Looks like a small buffer problem somewhere?
------------------------------------------------------------------------
[2015-07-02 12:05:06] jgeert1 at its dot jnj dot com
The odbc trace can be found here:
https://gist.githubusercontent.com/anonymous/761c084d36f586862f08/raw/SQLLOG
Thanks.
------------------------------------------------------------------------
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=69975
--
Edit this bug report at https://bugs.php.net/bug.php?id=69975&edit=1