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 segfaults when accessing nvarchar(max) defined
columns
Status: Verified
Type: Bug
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:
I've tested with odbcver=0x0350 and 0x0351 and got segfaults, too.
Actually the problem is rather clear in the meantime. According to
MSDN[1] nvarchar(max) has a maximum size of 2GB. Even if the
driver would report this as displaylength, so much memory could
usually not be allocated. Apparently, nvarchar(max) has to be
treated the same as SQL_WLONGVARCHAR. The SQL Server driver does
this, but not the SQL Server Native Client 11.0 driver
(2011.110.3000.0). The fix appears to be a no-brainer (similar to
the attached draft patch, but additionally setting .coltype to
SQL_WLONGVARCHAR, and of course fixing the assignment in the if
condition).
I can confirm that #68964 is already fixed. An ntext column is
reported as SQL_WLONGVARCHAR by both drivers (ODBCVER 03x00 as
well as 0x351).
Interestingly, bug #67437 suggests that some drivers report a size
of ~ 2GB for nvarchar(max). I'll have a closer look on that.
[1] <https://msdn.microsoft.com/en-us/library/ms186939(v=sql.120).aspx>
Previous Comments:
------------------------------------------------------------------------
[2015-07-02 20:04:44] ab@php.net
@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.
------------------------------------------------------------------------
[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>
------------------------------------------------------------------------
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