Edit report at https://bugs.php.net/bug.php?id=81688&edit=1
ID: 81688
Updated by: cmb@php.net
Reported by: calvin at cmpct dot info
Summary: PDO_ODBC doesn't handle fixed-length character
columns with character conversio
Status: Assigned
Type: Bug
Package: PDO ODBC
Operating System: IBM i 7.2
PHP Version: 8.0.13
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
> [â¦], just chuffed at the issue tracker that it got auto-closed.
Yeah, that is a bit unfortunate. If the status is set to
"feedback", the bug is automatically closed on the next but one
Sunday, even if feedback has been provided. You, as bug reporter,
should be able to change the status back to "open", though
("re-opened" doesn't work, IIRC).
> but I don't notice any different behaviour
Hmm, does the *driver* fill the buffers with some garbage at the
end, in this case? I'll have a closer look tomorrow; it seems
using SQLGetData() always (for testing purposes) might be a way to
proceed.
Previous Comments:
------------------------------------------------------------------------
[2021-12-27 21:32:34] calvin at cmpct dot info
Thankfully was a quick build, but I don't notice any different behaviour (where /tmp/php is a
build of PHP-8.0.14 with your patch vs. my system 8.0.13 from Fedora, both using the Linux build of
the same driver I've been using on i):
```
[calvin@salient src]$ /tmp/php/bin/php -d
extension_dir=/tmp/php/lib/php/extensions/no-debug-non-zts-20200930 test4.php
before ODBC
bool(true)
after ODBC
Record
string(180)
"éééééééééééééééééééééééééééééé
V��(���j"
Record
string(165) "ééééééééééééééé
"
Record
string(155) "ééééé
"
[calvin@salient src]$ php test4.php
before ODBC
bool(true)
after ODBC
Record
string(180)
"éééééééééééééééééééééééééééééé
�c��]"
Record
string(165) "ééééééééééééééé
�c��]"
Record
string(155) "ééééé
"
```
------------------------------------------------------------------------
[2021-12-27 21:16:32] calvin at cmpct dot info
Testing your patch and it faults, but it segfaults on the additional memset. Bizarre, so I'm
gonna check if it reproduces the same on Linux.
```
(gdb) run
Starting program: /QOpenSys/pkgs/bin/php -d error_log= test4.php
[New Thread 1]
before ODBC
bool(true)
after ODBC
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1]
0x000000000000000c in ?? ()
(gdb) sharedlib odbc
Reading symbols from /QOpenSys/pkgs/lib/libodbcinst.so.2(shr_64.o)...done.
Reading symbols from /QOpenSys/pkgs/lib/libcwbodbc.so...done.
Reading symbols from /QOpenSys/pkgs/lib/php-8.0/extensions/pdo_odbc.so...done.
Reading symbols from /QOpenSys/pkgs/lib/libodbc.so.2(shr_64.o)...done.
Reading symbols from /QOpenSys/pkgs/lib/php-8.0/extensions/odbc.so...done.
(gdb) where
#0 0x000000000000000c in ?? ()
#1 0x090000004e2862d0 in php_odbc_fetch_hash.isra.11.constprop () from
/QOpenSys/pkgs/lib/php-8.0/extensions/odbc.so
#2 0x00000001000b9914 in execute_ex (ex=0x70000000022ffe0) at
/home/calvin/rpmbuild/BUILD/php-8.0.14/Zend/zend_execute.c:51782
#3 0x00000001000c1f30 in zend_execute (op_array=0x70000000022ffe0, return_value=0x7) at
/home/calvin/rpmbuild/BUILD/php-8.0.14/Zend/zend_execute.c:58537
#4 0x00000001000e5b80 in zend_execute_scripts (type=2293728, retval=0x7, file_count=0) at
/home/calvin/rpmbuild/BUILD/php-8.0.14/Zend/zend.c:1680
#5 0x00000001001d1ff4 in php_execute_script (primary_file=0xfffffffffffdec0) at
/home/calvin/rpmbuild/BUILD/php-8.0.14/main/main.c:2539
#6 0x0000000100002d00 in do_cli (argc=4, argv=0x1800ee770) at
/home/calvin/rpmbuild/BUILD/php-8.0.14/sapi/cli/php_cli.c:347
#7 0x00000001000008cc in main (argc=4, argv=0x7) at
/home/calvin/rpmbuild/BUILD/php-8.0.14/sapi/cli/php_cli.c:1337
```
------------------------------------------------------------------------
[2021-12-27 19:42:10] calvin at cmpct dot info
Hi Christoph, I'll give this patch a shot (and see if Db2 has that column type...). I'm
fine with the late reply considering the season (time off is more important than ODBC bugs), just
chuffed at the issue tracker that it got auto-closed.
------------------------------------------------------------------------
[2021-12-27 16:51:04] cmb@php.net
Sorry for the late reply!
From what I can tell, there may be two different issues here: (a)
PHP does not allocate sufficient space for the data, and (b) the
driver may deliver fewer data than PHP expects, resulting in
arbitrary memory contents to be given to userland. Let's focus
on (b) for now, since that should be easy to fix by zeroing the
buffers before fetching. Could you please try the following patch
for ODBC (PDO_ODBC could likely get a similar fix):
ext/odbc/php_odbc.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/ext/odbc/php_odbc.c b/ext/odbc/php_odbc.c
index d4de4ec75b..d0ee19aa07 100644
--- a/ext/odbc/php_odbc.c
+++ b/ext/odbc/php_odbc.c
@@ -1381,6 +1381,12 @@ static void php_odbc_fetch_hash(INTERNAL_FUNCTION_PARAMETERS, int
result_type)
RETURN_FALSE;
}
+ for (i = 0; i < result->numcols; i++) {
+ if (result->values[i].value != NULL) {
+ memset(result->values[i].value, 0, result->values[i].vallen);
+ }
+ }
+
#ifdef HAVE_SQL_EXTENDED_FETCH
if (result->fetch_abs) {
if (rownum > 0) {
Something else that may be worth investigating is the usage of
SQL_LONGVARCHAR columns (or respective casts), if something like
that is supported by the DB and the driver. Such columns are not
bound, but rather SQLGetData() is used to retrieve the data, and
the driver is supposed to report the length of the transferred
data in the StrLen_or_IndPtr argument (so in this case neither
SQLDescribeCol() nor SQLColAttribute() are used to compute the
length).
------------------------------------------------------------------------
[2021-12-27 13:56:18] calvin at cmpct dot info
The problem still exists, it should be re-opened.
That said, I'm not entirely sure of the etiquette though around bugs on bugs.php; are these
better off moved to GH Issues instead now?
------------------------------------------------------------------------
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=81688
--
Edit this bug report at https://bugs.php.net/bug.php?id=81688&edit=1