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
Type: Feature/Change Request
Package: ODBC related
Operating System: Windows Server 2012R2
PHP Version: 5.5.26
Block user comment: N
Private report: N
New Comment:
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>
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2015-07-02 11:12:03] cmb@php.net
> Anyway if there's anything I can (investigate,test,..), just let
> me know as I really would like this to be resolved.
It might be helpful if you can post an ODBC trace for the given
test script. If the trace is large, it might be best to put it on
<https://gist.github.com/> or someone else, but not
directly in
this ticket. How to create an ODBC trace is described on
<https://support.microsoft.com/en-us/kb/274551>.
And please make
sure there is no confidential information contained in the trace
(password etc.)
------------------------------------------------------------------------
[2015-07-02 07:27:19] jgeert1 at its dot jnj dot com
Thanks for your fast reply.
Don't get me wrong here, I'm really satisfied with the work that you guys are doing here.
And I'm even impressed by the quality of it.
I just looked at #68964 and yes it's almost the same issue. I also had that same error in the
beginning (memory exhausted), but when I changed the max memory limit in php.ini to 1024M, the error
did not show up again, instead Apache started crashing as a result of it.
The database server (seperate system) is running SQL Server 11.0.5058 (SQL Server 2012). The ODBC
driver I'm using is "SQL Server Native Client 11.0" (2011.110.2100.60).
The database is using some tables with columns defined as "nvarchar(max)", this type is
not deprecated as you've mentioned, it's even recommended to use them ("ntext",
"text" and "image" types are deprecated).
When I'm using the "SQL Server Native Client 11.0" odbc driver, I notice that the
columns are reported (using the odbc_columns calls) as "nvarchar(0)". But when I'm
using the "SQL Server" odbc server, these same columns are reported as "ntext"
with a size of 2147483646 eventhough it's the same column in the database wich is indeed
defined as "nvarchar(max)".
Anyway if there's anything I can (investigate,test,..), just let me know as I really would like
this to be resolved.
Currenlty I'm using the 64-bit versions of Apache and PHP.
Thanks.
------------------------------------------------------------------------
[2015-07-01 14:42:58] ab@php.net
fix category
------------------------------------------------------------------------
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