Edit report at https://bugs.php.net/bug.php?id=69975&edit=1
ID: 69975
Updated by: ab@php.net
Reported by: jgeert1 at its dot jnj dot com
-Summary: PHP segfaults when accessing nvarchar(max) defined
columns
+Summary: PHP is causing Apache to crash when accessing
nvarchar(max) defined columns
Status: Verified
Type: Feature/Change Request
Package: ODBC related
Operating System: Windows Server 2012R2
PHP Version: 5.5.26
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
@jgeert1, ahh, you're right. Still, it could be a driver mess.
@cmb, have you tried to raise the ODBCVER? See ext/odbc/config.w32, IMHO 3.5 could be done for
master, if there's no other solution. Still many issues with 3.0 and older. But on the other
hand, if you can fix it with 3.0, so be.
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2015-07-02 16:59:23] cmb@php.net
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.
------------------------------------------------------------------------
[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?
------------------------------------------------------------------------
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