MySQL Bugs: #116657: Retrieving list of records that contain an empty blob causes undefined behaviour

Bug #116657	Retrieving list of records that contain an empty blob causes undefined behaviour
Submitted:	14 Nov 12:44	Modified:	15 Nov 7:18
Reporter:	Stuart Smith	Email Updates:
Status:	Verified	Impact on me:	None
Category:	Connector / ODBC	Severity:	S3 (Non-critical)
Version:	8.0.40	OS:	Windows (Windows11)
Assigned to:	Rafal Somla	CPU Architecture:	x86

Description:
Retrieving a list of records that contain an empty blob causes undefined behavior or invalid value. I've been able to reproduce using a perl script and C++ application making use of the ODBC driver and confirm it fails in both implementations.

How to repeat:
1. Create a table that contains a blob field.
CREATE TABLE blob_test (data BLOB)

2. Insert a record - blob field with 1 or more bytes.

my $x = '12345';
INSERT INTO blob_test (data) VALUES (?)

3. Insert another record - empty blob field (zero bytes)
my $y = '';
INSERT INTO blob_test (data) VALUES (?)

4. Retrieve records and list values.

SELECT data FROM blob_test

Output for perl script:

BLOB field lengths:
Length: 5 bytes
Content: 12345

Length: 11 bytes
Content: 12345e=file

Output for mysql cli:
mysql> select * from blob_test;
+-------+
| data  |
+-------+
| 12345 |
|       |
+-------+

Suggested fix:
I've tried to go down that rabbit hole, but no luck. I can confirm it works up to 8.0.26. I've tried several versions all the way up to 8.0.40 with undefined behavior.

Prevents us from upgrading MySql 8.0.40 ODBC driver

Hi Mr. Smith,

Thank you for your bug report.

Can you let us know the exact releases of C/C++ C/Perl, C/ODBC, version of Windows and it's ODBC system, so that we can attempt to repeat the behaviour.

We are waiting on your feedback.

Perl details: 5, version 38, subversion 2 (v5.38.2)
C++ details: MSVC version 19.29.30151 (192930151)
ODBC Driver Version: 08.00.0040 ODBC Version: 03.80.0000 Driver ODBC Version: 03.80
ODBC Manager: Windows ODBC Manager 64-bit

FYI: All of the above is 64bit

Thanks for the additional details.
Since you mentioned it can you provide the C++ test case as well?

Unfortunately I can't provide the C++ code as it's part of a solution. I did however include the ODBC SQL trace, hopefully that can help. When I compared the sql logs they SQLExecute, SQLFetch and bindings had the same settings.

I was able to reproduce the problem with one of my standard test cases.
The bug is verified.

Brilliant news! Shout if you need anything more.