Edit report at https://bugs.php.net/bug.php?id=81688&edit=1
ID: 81688
Comment by: calvin at cmpct dot info
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:
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
```
Previous Comments:
------------------------------------------------------------------------
[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?
------------------------------------------------------------------------
[2021-12-26 04:22:08] 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.
------------------------------------------------------------------------
[2021-12-14 18:53:44] calvin at cmpct dot info
I can confirm that PDO::ODBC_ATTR_ASSUME_UTF8 and using the procedural ODBC extension have the same
results. (Well, the garbage on the end is different, but it's still garbage and the string is
still the same length.)
Code for the procedural ODBC version (the attrib on PDO ver is trivial so not including):
```
$odbc = odbc_connect($dsn, $user, $pw);
$sql = "select cast(x as char(150)) as X from calvin.bigchars";
$stmt = odbc_prepare($odbc, $sql);
echo "before ODBC\n";
var_dump(odbc_execute($stmt));
echo "after ODBC\n";
while($record = odbc_fetch_array($stmt)){
echo "Record\n";
var_dump($record["X"]);
}
```
------------------------------------------------------------------------
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