Bug #79277 [Com]: pdo_odbc accessing SAP 16.0 ASE Fatal error: Allowed memory size ...

Edit report at https://bugs.php.net/bug.php?id=79277&edit=1 ID: 79277 Comment by: hleung at isfactory dot com Reported by: khleung at isfactory dot com Summary: pdo_odbc accessing SAP 16.0 ASE Fatal error: Allowed memory size ... Status: No Feedback Type: Bug Package: PDO ODBC Operating System: CentOS 7 PHP Version: 7.4.2 Assigned To: cmb Block user comment: N Private report: N New Comment: [sybase@localhost ~]$ php sybconnect.php dsn: odbc:SB007H Connected to ASE 16 displaysize == 255 displaysize == 11 displaysize == 11 displaysize == 2 displaysize == 6 displaysize == 6 displaysize == 6 displaysize == 6 displaysize == 11 displaysize == 23 displaysize == 23 displaysize == 11 displaysize == 11 displaysize == 11 displaysize == 11 displaysize == 11 displaysize == 6 displaysize == 11 displaysize == 6 displaysize == 24 displaysize == 30 displaysize == 39 displaysize == 6 displaysize == 16 displaysize == 6 displaysize == 3 displaysize == 3 displaysize == 11 displaysize == 11 Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4294967320 bytes) in /home/sybase/sybconnect.php on line 14 [sybase@localhost ~]$ Previous Comments: ------------------------------------------------------------------------ [2020-03-22 04:22:10] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Re-Opened". Thank you. ------------------------------------------------------------------------ [2020-03-08 17:24:59] cmb@php.net Thanks for checking! Unfortunately, it's hard to guess what's going on without being able to reproduce, and also because the ODBC trace lacks some relevant information about out parameters (although it looks generally fine). I can imagine that the displaysize returned by SQLColAttribute() is negative, but even in that case I cannot track down where that excessive allocation would happen. Still, it might help to try with the following patch, which should print the retrieved displaysizes to stderr: ext/pdo_odbc/odbc_stmt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/ext/pdo_odbc/odbc_stmt.c b/ext/pdo_odbc/odbc_stmt.c index 18abc475b9..0d3cb45352 100644 --- a/ext/pdo_odbc/odbc_stmt.c +++ b/ext/pdo_odbc/odbc_stmt.c @@ -608,6 +608,7 @@ static int odbc_stmt_describe(pdo_stmt_t *stmt, int colno) return 0; } } + fprintf(stderr, "displaysize == %d\n", displaysize); colsize = displaysize; col->maxlen = S->cols[colno].datalen = colsize; ------------------------------------------------------------------------ [2020-03-08 07:48:05] khleung at isfactory dot com [root@localhost ext]# cd /usr/local/src/php-7.4.2/ext/pdo_odbc/ [root@localhost pdo_odbc]# ls config.m4 CREDITS odbc_driver.lo odbc_stmt.c odbc_stmt.o pdo_odbc.lo php_pdo_odbc.h tests config.w32 odbc_driver.c odbc_driver.o odbc_stmt.lo pdo_odbc.c pdo_odbc.o php_pdo_odbc_int.h [root@localhost pdo_odbc]# vi odbc_stmt.c static int odbc_stmt_describe(pdo_stmt_t *stmt, int colno) { pdo_odbc_stmt *S = (pdo_odbc_stmt*)stmt->driver_data; struct pdo_column_data *col = &stmt->columns[colno]; RETCODE rc; SWORD colnamelen; SQLULEN colsize; SQLLEN displaysize = 0; ... :wq [root@localhost pdo_odbc]# cd /usr/local/src/php-7.4.2/ [root@localhost php-7.4.2]# make /bin/sh /usr/local/src/php-7.4.2/libtool --silent --preserve-dup-deps --mode=install cp ext/opcache/opcache.la /usr/local/src/php-7.4.2/modules /bin/sh /usr/local/src/php-7.4.2/libtool --silent --preserve-dup-deps --mode=compile cc -I/usr/local/src/php-7.4.2/ext -I/usr/include -DPDO_ODBC_TYPE=\"unixODBC\" -Iext/pdo_odbc/ -I/usr/local/src/php-7.4.2/ext/pdo_odbc/ -DPHP_ATOM_INC -I/usr/local/src/php-7.4.2/include -I/usr/local/src/php-7.4.2/main -I/usr/local/src/php-7.4.2 -I/usr/local/src/php-7.4.2/ext/date/lib -I/usr/include/libxml2 -I/usr/local/src/php-7.4.2/TSRM -I/usr/local/src/php-7.4.2/Zend -I/usr/include -g -O2 -fvisibility=hidden -Wall -Wno-strict-aliasing -DZEND_SIGNALS -c /usr/local/src/php-7.4.2/ext/pdo_odbc/odbc_stmt.c -o ext/pdo_odbc/odbc_stmt.lo /usr/local/src/php-7.4.2/ext/pdo_odbc/odbc_stmt.c: In function ‘odbc_stmt_describe’: /usr/local/src/php-7.4.2/ext/pdo_odbc/odbc_stmt.c:573:4: warning: pointer targets in passing argument 3 of ‘SQLDescribeCol’ differ in signedness [-Wpointer-sign] &S->cols[colno].coltype, &colsize, NULL, NULL); ^ In file included from /usr/include/sqlext.h:43:0, from /usr/include/sqlucode.h:784, from /usr/local/src/php-7.4.2/ext/pdo_odbc/php_pdo_odbc_int.h:53, from /usr/local/src/php-7.4.2/ext/pdo_odbc/odbc_stmt.c:29: /usr/include/sql.h:644:24: note: expected ‘SQLCHAR *’ but argument is of type ‘char *’ SQLRETURN SQL_API SQLDescribeCol(SQLHSTMT StatementHandle, ^ /usr/local/src/php-7.4.2/ext/pdo_odbc/odbc_stmt.c: In function ‘odbc_stmt_set_param’: /usr/local/src/php-7.4.2/ext/pdo_odbc/odbc_stmt.c:781:4: warning: pointer targets in passing argument 2 of ‘SQLSetCursorName’ differ in signedness [-Wpointer-sign] rc = SQLSetCursorName(S->stmt, Z_STRVAL_P(val), Z_STRLEN_P(val)); ^ In file included from /usr/include/sqlext.h:43:0, .... Build complete. Don't forget to run 'make test'. [root@localhost php-7.4.2]# make install Installing shared extensions: /usr/lib/php/extensions/no-debug-non-zts-20190902/ Installing PHP CLI binary: /usr/bin/ Installing PHP CLI man page: /usr/php/man/man1/ Installing phpdbg binary: /usr/bin/ Installing phpdbg man page: /usr/php/man/man1/ Installing PHP CGI binary: /usr/bin/ Installing PHP CGI man page: /usr/php/man/man1/ Installing build environment: /usr/lib/php/build/ Installing header files: /usr/include/php/ Installing helper programs: /usr/bin/ program: phpize program: php-config Installing man pages: /usr/php/man/man1/ page: phpize.1 page: php-config.1 /usr/local/src/php-7.4.2/build/shtool install -c ext/phar/phar.phar /usr/bin ln -s -f phar.phar /usr/bin/phar Installing PDO headers: /usr/include/php/ext/pdo/ [root@localhost php-7.4.2]# exit [sybase@localhost ~]$ cd ~ [sybase@localhost ~]$ php sybconnect.php dsn: odbc:SB007H Connected to ASE 16 Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4294967320 bytes) in /home/sybase/sybconnect.php on line 14 [sybase@localhost ~]$ which php /usr/bin/php [sybase@localhost ~]$ ls -l /usr/bin/php -rwxr-xr-x. 1 root root 32209632 Mar 8 23:34 /usr/bin/php ------------------------------------------------------------------------ [2020-03-08 04:22:04] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Re-Opened". Thank you. ------------------------------------------------------------------------ [2020-02-23 12:05:24] cmb@php.net Thanks for the ODBC trace, and sorry for the late reply! It seems to me that we are not properly handling the retrieval of the display size; the MS documentation of SQLColAttribute()[1] 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. So can you please try the attached init-displaysize patch? [1] <https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlcolattribute-function> ------------------------------------------------------------------------ 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=79277 -- Edit this bug report at https://bugs.php.net/bug.php?id=79277&edit=1