Hi,I have attached the patch, the corresponding commit is https://github.com/mariadb-corporation/mariadb-connector-odbc/commit/1346a8278596f883ae8bf5262b70f0ede19cfdd1
Patrick Braun On 23/06/2025 10:28, Bernhard Schmidt wrote:
Hi,I've uploaded 3.1.15-4, but did not include ODBC-365 (and not the unit test either, as the whole test/ folder is missing in the 3.1.15 release).Do you have a diff for ODBC-365? Bernhard Am 23.06.25 um 09:55 schrieb Patrick Braun:Hey all,I'll test the patched release, no problem. Though if you want to import ODBC-359, I'd suggest importing ODBC-365 as well. My initial fix corrected the segfault but didn't return the required buffer length, which ODBC-365 then fixes.If you need anything else feel free to ping me. Patrick Braun On 20/06/2025 22:04, Bernhard Schmidt wrote:Hi, aww shit, sorry I missed that (btw, always feel free to NMU this).This late in the freeze I don't think we can update to 3.1.21, but I think we can import the fix for ODBC-359.@Patrick: When I upload a 3.1.15-4 targeted for Trixie, would you be able to test it before I ask for an unblock?Bernhard Am 20.06.25 um 20:13 schrieb Otto Kekäläinen:Hi Bernhard! Thanks for maintaining the ODBC connector for MariaDB in Debian! Could you please update it to latest version? Note also that MariaDB 11.8 LTS recently landed in Debian.Package: odbc-mariadb Version: 3.1.15-3 Severity: wishlist Dear Maintainers,the current 3.1.15 release contains several bugs. I specifically hit https://jira.mariadb.org/browse/ODBC-359. I have updated the package to the 3.1.21 upstream release in a fork and am runnign it on several bullseye and bookworm systems with no issues. The 3.2 branch seems to exist as well but I haven't looked at it much. I'm not that well versed in the official debian workflow so I haven't opened a PR or the like. The fork is at https:// salsa.debian.org/pbraun/mariadb-connector-odbcI'd gladly assist if I can be of any help.
From 1346a8278596f883ae8bf5262b70f0ede19cfdd1 Mon Sep 17 00:00:00 2001 From: Lawrin Novitsky <[email protected]> Date: Mon, 13 Jun 2022 15:32:35 +0200 Subject: [PATCH] ODBC-365 The fix only(the testcase of ODBC-359 covers it) If application wanted to know length of wchar data(to allocate the buffer and later fetch it) - i.e. it SQLBindCol only lenght pointer, and no data pointer, on SQLFetch connector would put 0 in the length buffer. Usually that is done with SQLGetData, but this way is also legitimate. --- ma_statement.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/ma_statement.c b/ma_statement.c index 820da1e..415e36b 100644 --- a/ma_statement.c +++ b/ma_statement.c @@ -1911,12 +1911,19 @@ SQLRETURN MADB_FixFetchedValues(MADB_Stmt *Stmt, int RowNumber, MYSQL_ROW_OFFSET *Stmt->stmt->bind[i].length, &Stmt->Error); /* If returned len is 0 while source len is not - taking it as error occurred */ - if ((CharLen == 0 || (SQLULEN)CharLen > (ArdRec->OctetLength / sizeof(SQLWCHAR))) && *Stmt->stmt->bind[i].length != 0 && Stmt->result[i].buffer != NULL && *(char*)Stmt->result[i].buffer != '\0' && Stmt->Error.ReturnValue != SQL_SUCCESS) + if ((CharLen == 0 || + (SQLULEN)CharLen > (ArdRec->OctetLength / sizeof(SQLWCHAR))) && *Stmt->stmt->bind[i].length != 0 && Stmt->result[i].buffer != NULL && + *(char*)Stmt->result[i].buffer != '\0' && Stmt->Error.ReturnValue != SQL_SUCCESS) { CALC_ALL_FLDS_RC(rc, Stmt->Error.ReturnValue); } + /* If application didn't give data buffer and only want to know the length of data to fetch */ + if (CharLen == 0 && *Stmt->stmt->bind[i].length != 0 && Stmt->result[i].buffer == NULL) + { + CharLen= *Stmt->stmt->bind[i].length; + } /* Not quite right */ - *LengthPtr= CharLen * sizeof(SQLWCHAR); + *LengthPtr = CharLen * sizeof(SQLWCHAR); } break; -- 2.47.2
smime.p7s
Description: S/MIME Cryptographic Signature
