MySQL Bugs: #117005: ODBC Driver 8.4 GetDataTypeName returns bad and random values

Bug #117005	ODBC Driver 8.4 GetDataTypeName returns bad and random values
Submitted:	18 Dec 9:14	Modified:	19 Dec 4:10
Reporter:	Timo Hyrsylä	Email Updates:
Status:	Verified	Impact on me:	None
Category:	Connector / ODBC	Severity:	S2 (Serious)
Version:	MySql ODBC 8.4	OS:	Windows
Assigned to:		CPU Architecture:	Any (64-bit)

Description:
c# OdBcDataReader.GetDataTypeName( n ) returns null and random values that look like bad pointer references somewhere.

Same output also seen with driver version 9.1

// unrelated issue:
(
And why I try 8.4 is since 9.1 crashes on connect, although only on our production software, the simple test-app here seems to work ok:
Component Prog ID: a[ODBC][Env 00000148CD2BC7C0]
Method Name: IDispenserDriver::CreateResource
Process Name: mfappplatform.exe
Exception: c0000005
Address: 0X00007FFD95B232F8
)

How to repeat:
using System.Data.Common;
using System.Data.Odbc;
using System.Diagnostics;

class Program
{
	static void Main( string[] args )
	{
		var dsn = args.Length > 1 ? args[ 0 ] : "mysli";
		var table = args.Length > 1 ? args[ 1 ] : "atable";

		var constr = "DSN=" + dsn;
		var cmdstr = "SELECT * FROM " + table;

		using( var con = new OdbcConnection( constr ) )
		{
			con.Open();
			Console.WriteLine( "Columns of table " + table + " by describe:" );
			using( DbCommand cmd = new OdbcCommand( "describe " + table, con ) )
			{
				using( DbDataReader reader = cmd.ExecuteReader() )
				{
					while( reader.Read() )
					{
						Console.WriteLine( $"{reader.GetValue( 0 )} = {reader.GetValue( 1 )} " );
					}

				}
			}

			Console.WriteLine( "\nDatatypes of columns by GetDatatypeName and GetFieldType" );
			using( DbCommand cmd = new OdbcCommand( cmdstr, con ) )
			{
				// Execute reader.
				using( DbDataReader reader = cmd.ExecuteReader() )
				{
					// Convert info to ColumnDefinitions.
					for( var i = 0; i < reader.FieldCount; i++ )
					{
						var typename = reader.GetDataTypeName( i );
						var type = reader.GetFieldType( i );

						Console.WriteLine( $"{reader.GetName( i )} = \"{typename}\"  vs.  {type.Name}" );
					}
				}
			}
		}
	}
}

// Connecting to my test DB on db4free.net outputs the following:
// The values of GetDataTypeName differ by each run.

Columns of table atable by describe:
a = int
b = tinyint(1)
c = varchar(20)
d = double
e = text
f = tinyint
g = smallint
h = mediumint
i = bigint
decimal = decimal(10,0)
float = float
double = double
real = double
bit = bit(3)
abool = tinyint(1)
aserial = bigint unsigned
adate = date
adatetime = datetime
atimestamp = timestamp
atime = time
ayear = year
achar = char(9)
avarchar = varchar(254)
atinytext = tinytext
amedtext = mediumtext
alongtext = longtext
abinary = binary(155)
avarbinary = varbinary(123)
aenum = enum('a','b','e','f')
aset = set('one','othre','more','none')
ageo = geometry
apoint = point
apoly = polygon
ajson = json

Datatypes of columns by GetDatatypeName and GetFieldType
a = "integer"  vs.  Int32
b = "tinyint"  vs.  Int16
c = ""  vs.  String
d = "double"  vs.  Double
e = ""  vs.  String
f = ""  vs.  Int16
g = "double"  vs.  Int16
h = "bit"  vs.  Int32
i = "tinyint"  vs.  Int64
decimal = ▼"  vs.  Decimal
float = ""  vs.  Single
double = ""  vs.  Double
real = "y"  vs.  Double
bit = "bit"  vs.  Byte[]
abool = "Xb"  vs.  Int16
aserial = ""  vs.  Decimal
adate = "(]"  vs.  DateTime
adatetime = "8`"  vs.  DateTime
atimestamp = ""  vs.  DateTime
atime = "time"  vs.  TimeSpan
ayear = "year"  vs.  Int32
achar = "char"  vs.  String
avarchar = "varchar"  vs.  String
atinytext = "text"  vs.  String
amedtext = "text"  vs.  String
alongtext = "longtext"  vs.  String
abinary = "binary"  vs.  Byte[]
avarbinary = "varbinary"  vs.  Byte[]
aenum = "char"  vs.  String
aset = "char"  vs.  String
ageo = "geometry"  vs.  Byte[]
apoint = "geometry"  vs.  Byte[]
apoly = "geometry"  vs.  Byte[]
ajson = "json"  vs.  String

Occurs when using .Net Framework 4.7.2 and 4.8 or .Net 8.0

Hi Mr. Hyrsyla,

Thank you for your bug report.

However, we are not sure what category should this report belong to. 

Is it a problem with .Net or is it a problem with ODBC ????

Also, we require the full test case. That includes tables and their contents.

We can not repeat without these data.

Can't repeat.

Hi Mr. Hyrsyla,

Recently we became aware of the ODBC Driver 8.4 and  9.1 malfunctions or  crashes caused by runtime libraries inside Visual C++ Redistributable package 2015-2022 version 14.36. Updating the VC++ package to version 14.40 or newer should resolve the problem with the crashes. Make sure that the redistributable package for x64 architecture is updated.

Please try this and let us know if it worked.

Hi,

Your problem is definitely not with libraries .....

Our Connector's team will try to repeat your test case during next week, since we have arrived near the holiday season.

Dear Mr. Hyrsylä,

Thank you for providing the test code and sample data
We were able to repeat the problem.

The bug is now verified.
We will do the diagnosis and post updates on our findings into this ticket.

Thank you, Bogdan.

Posted by developer:
 
Preliminary Diagnosis of the issue:

To get the type name information in C# the user code has the following line:

OdBcDataReader.GetDataTypeName(N);

The above function does ODBC API call like this:

MySqlTest.net   6e5c-5210 ENTER SQLColAttributeW 
	SQLHSTMT          0x0000029FD222CA60
	SQLSMALLINT       1 
	SQLSMALLINT       14 <SQL_DESC_TYPE_NAME>
	SQLPOINTER        0x0000029FEC468FF0
	SQLSMALLINT       4096 
	SQLSMALLINT *     0x000000A9167FEEE8
	SQLPOINTER        0x000000A9167FEE88 (NYI) 

MySqlTest.net   6e5c-5210  EXIT  SQLColAttributeW  with return code 0 (SQL_SUCCESS)
	SQLHSTMT           0x0000029FD222CA60
	SQLSMALLINT        1 
	SQLSMALLINT        14 <SQL_DESC_TYPE_NAME>
	SQLPOINTER         0x0000029FEC468FF0
	SQLSMALLINT        4096 
	SQLSMALLINT *      0x000000A9167FEEE8 (0)
	SQLPOINTER         0x000000A9167FEE88 (NYI) 

The column attribute SQL_DESC_TYPE_NAME requested by the user application is obtained from IRD internally.
The type information in IRD is not properly initialized, that is why the driver returns garbage in the output buffer.

Thank you, Bogdan.