Bug #109466 A SQLProcedureColumns followed by a SQLFreeStmt causes a crash
Submitted: 22 Dec 2022 8:22 Modified: 20 Dec 2024 22:44
Reporter: Ruedi Gloor Email Updates:
Status: Closed Impact on me:
None 
Category:Connector / ODBC Severity:S3 (Non-critical)
Version:8.3, 8.4, 9.0 OS:Windows
Assigned to: CPU Architecture:Any

[22 Dec 2022 8:22] Ruedi Gloor
Description:
When using the ODBC C API a crash occurs when calling SQLProcedureColumns followed by SQLFreeStmt after successfully establishing a connection.

The version of the server that it is connecting to is 8.0.31.

It seams like stmt->reset(); on line 498 in handle.cc deletes the result fields. When SQLNumResultCols tries to read the fields MySQLODBC crashes.

When these commands were run against a Microsoft SQL Server database they completed successfully.

The same commands also work with version <= 8.0.25 of the MySQL ODBC Driver.

How to repeat:
1.  Establish an ODBC connection to a MySQL database through the MySQL ODBC driver.

2.  Once the connection is established make these three function calls:

    ret = SQLProcedureColumns(hStmt, NULL, 0, NULL, 0, L"spTest", SQL_NTS, NULL, 0);
    ret = SQLFreeStmt(hStmt, SQL_UNBIND);
    ret = SQLNumResultCols(hStmt, &size);
    TRYODBC(hStmt, SQL_HANDLE_STMT, SQLNumResultCols(hStmt,&sNumResults));
[22 Dec 2022 8:24] Ruedi Gloor
C++ program to reproduce the bug.

Attachment: SQLProcedureColumns.zip (application/x-zip-compressed, text), 7.12 KiB.

[3 Nov 2023 6:39] Ruedi Gloor
I reported this bug almost a year ago. Does anybody care about that?
[23 Apr 2024 12:29] MySQL Verification Team
Hello Ruedi Gloor,

Thank you for the bug report.
Please upgrade to latest version and report us back if issue persist even in latest version along with test case. Thank you.

Regards,
Ashwini Patil
[24 Apr 2024 7:10] Ruedi Gloor
The error persists with MySQL ODBC Driver 8.3.0.
[31 Jul 2024 13:28] MySQL Verification Team
Hello Ruedi Gloor,

Thank you for the update.
I tried to reproduce your issue on windows 11 with Connector/ODBC 8.3, 8.4 and 9.0 using the program attached but I am not seeing any issues at my end. 

Regards,
Ashwini Patil
[31 Jul 2024 13:33] MySQL Verification Team
9.0.0 test results

Attachment: 109466_test_results.png (image/png, text), 42.39 KiB.

[31 Jul 2024 15:34] Ruedi Gloor
I tested it again and the error persist. But I didn't write that you need to create the stored procedure spTests with parameters in your database. I am sorry for that.

So please create spTest in your database:

CREATE DEFINER=`root`@`%` PROCEDURE `spTest`(
	IN `iParam1` INT,
	OUT `iParam2` INT
)
BEGIN
	SELECT iParam1 INTO iParam2;
END

Create a ODBC connection, as database you chose this database, execute the test program and chose this ODBC DSN. The Program should crash.
[1 Aug 2024 12:27] MySQL Verification Team
Hello Ruedi Gloor,

Thank you for the details.
Verified as described after creating stored procedure.

Regards,
Ashwini Patil
[18 Dec 2024 11:44] Bogdan Degtyariov
Posted by developer:
 
Documenting comment:

The patch changes the handling of result sets produced by catalog functions.
If SQLFreeStmt() with SQL_UNBIND or SQL_RESET_PARAMS is called after a catalog function (such as SQLProcedureColumns) the result set produced by this catalog function is not cleared in accordance to ODBC API requirements for unbinding result columns and resetting parameters.

patch revision 1f369ccc29fcfe96041c0b6763b59f68dc4ef57d
[18 Dec 2024 12:26] Ruedi Gloor
Where can I find this patch revision 1f369ccc29fcfe96041c0b6763b59f68dc4ef57d?
[20 Dec 2024 22:44] Philip Olson
Posted by developer:
 
Fixed as of the upcoming MySQL Connector/ODBC 9.2.0 release, and here's the proposed changelog entry from the documentation team:

Improved result set handling produced by catalog functions. When
SQLFreeStmt() with SQL_UNBIND or SQL_RESET_PARAMS was called after a
catalog function (such as SQLProcedureColumns), the result set produced by
the catalog function was not cleared in accordance to ODBC API
requirements for unbinding result columns and resetting parameters.

Thank you for the bug report.