MySQL Bugs: #36370: ODBC CRASH WHEN FIELDS of CHARSET ANSI ARE FETCED

Bug #36370	ODBC CRASH WHEN FIELDS of CHARSET ANSI ARE FETCED
Submitted:	28 Apr 2008 9:36	Modified:	24 Feb 2010 13:27
Reporter:	Dimitris Klaras	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / ODBC	Severity:	S2 (Serious)
Version:	5.1.5 32 bit	OS:	Windows (WinXP SP2)
Assigned to:		CPU Architecture:	Any

Description:
In prepared SQL statements when fetced a field with column charset ANSI, GREEK etc (not UNICODE, UTF8) driver crashes. If I convert the field to utf8, all work ok. This problem was not existed in ODBC version 3.51.19 I was using before.

How to repeat:
Make a prepared statement to a database with VARCHAR/CHAR fields and try to fetch one of those fields. If the field is fetched and is charset ANSI (also I tested i with Greek), the SQLFetch crashes. If the fetced field is converted to utf8 in the database then all work ok.

correcting OS details

charset ANSI has to be corrected with charset ASCII.

I tested it with a non prepared statement (SQLExecDirect) and I got the same behavior.

Hi Dimitris and thanks for your report.

I would like you to attach following info to this report:
  - mysql cl client output from SHOW VARIABLES LIKE "char%"
  - mysql dump of small database we can use along with test case showing the error
  - crash dump

Simple database to show the crash and info file

Attachment: MySQL ODBC bug.zip (application/x-zip-compressed, text), 1.12 KiB.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Dimitris, I am sorry I missed your response. You should always revert status to "Open" after providing new info.

Now, I've found no problem with your test running on WinXP SP2 and MySQL server 5.0.60PB. MyODBC is 5.1.4GA and client is Microsoft generic ODBC client, odbcte32w.exe:

SQLExecDirect (select * from bug36370):
	In:hstmt = 0x00851FD0, szSqlStr = "", cbSqlStr = -3
	Return:	SQL_SUCCESS=0

Get Data All:
"aa", "bb"
"a1", "b1"
1 row fetched from 2 columns.

Looking into your server settings I think charset conversion takes place as database is set to Greek while connection is UTF8 (and results also, as set by MyODBC, "character_set_results utf8"). You should correct this situation (and don't use "SET NAMES" with MyODBC 5.1 if you're using it).
Further more, I'll need server log (general query log) around time error happens and a DM trace (see manual for details).

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

May be related to bug#36996

Create a database using the following character sets : ascii or armscii
where the server has the following set
SET character_set_client = latin1
SET character_set_results = latin1
SET character_set_connection = latin1

Create a table with the following script :
CREATE TABLE applab ( c1 char(1) NULL);
INSERT INTO applab  VALUES ( 'a' ); 

run SELECT * FROM applab
get a crash from SQLFetchScroll call

solution was to set the following after connecting
SET character_set_client = utf8
SET character_set_results = utf8
SET character_set_connection = utf8

This problem did not occur in 3.51.x driver

ODBC DM traces

Attachment: cODBC-32-and-64bit-traces.zip (application/x-zip-compressed, text), 4.26 KiB.

Doing things as Serge suggested truly leads to crash, but...

Environment: MySQL server 5.1.32 community on Win2K8x64 localhost.

Server version: 5.1.32-community-log MySQL Community Server (GPL)
mysql> show variables like "%char%";
+--------------------------+---------------------------------------------------+
| Variable_name            | Value
+--------------------------+---------------------------------------------------+
| character_set_client     | latin1
| character_set_connection | latin1
| character_set_database   | latin1
| character_set_filesystem | binary
| character_set_results    | latin1
| character_set_server     | latin1
| character_set_system     | utf8
| character_sets_dir       | C:\Program Files\MySQL\MySQL Server 5.1\share\chars
ets\ |
+--------------------------+---------------------------------------------------+

mysql> create database bug36370 character set ascii;
mysql> show create database bug36370;
+----------+-------------------------------------------------------------------+
| Database | Create Database
|
+----------+-------------------------------------------------------------------+
| bug36370 | CREATE DATABASE `bug36370` /*!40100 DEFAULT CHARACTER SET ascii */
+----------+-------------------------------------------------------------------+

mysql> use bug36370;
Database changed
mysql> create table tbl1(c1 char(1) NULL);
mysql> show create table tbl1;
+-------+----------------------------------------------------------------------+
| Table | Create Table
+-------+----------------------------------------------------------------------+
| tbl1  | CREATE TABLE `tbl1` (
  `c1` char(1) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=ascii |
+-------+----------------------------------------------------------------------+

mysql> insert into tbl1 values("a");
mysql> select * from tbl1;
+------+
| c1   |
+------+
| a    |
+------+

c/ODBC 3.51 32bit does not crash but fetches records:
3.51 32bit:
	Full Connect(Default)
	Env. Attr. SQL_ATTR_ODBC_VERSION set to SQL_OV_ODBC3
	Successfully connected to DSN '3-51-27-on-localhost'.
SQLExecDirect:
	In:hstmt = 0x001E5B20, szSqlStr = "SELECT * FROM tbl1", cbSqlStr = -3
	Return:	SQL_SUCCESS=0
Get Data All:
"c1"
"a"
1 row fetched from 1 column.

c/ODBC 5.1 *32bit* crashes odbcte32w.exe right after fetching column name.

c/ODBC 5.1 *64bit* throws error right after fetching column name:
	Full Connect(Default)
	Env. Attr. SQL_ATTR_ODBC_VERSION set to SQL_OV_ODBC3
	Successfully connected to DSN '5-1-05-local'.
SQLExecDirect:
	In:	hstmt = 0x000000000072D960, szSqlStr = "", cbSqlStr = -3
	Return:	SQL_SUCCESS=0
Get Data All:
"c1"
ERROR
SQLGetData returned: SQL_ERROR=-1

Now, from attached traces, one can see where the problem is and that Jess was probably right:
odbct32w        8cc-c64	EXIT  SQLGetData  with return code -1 (SQL_ERROR)
		HSTMT               000000000064F460
		UWORD                        1 
		SWORD                        1 <SQL_C_CHAR>
		PTR                 0x00000000001B2A10 (NYI) 
 		SQLLEN             SQLLEN	SQLLEN*	SQLLEN*           
		DIAG [07006] [MySQL][ODBC 5.1 Driver][mysqld-5.1.32-community-log]Source character set not supported by client (0) 

Triage is severe as there is a *crash* in client after all.

There is nothing of interest in general query log.

Crashes also with MyISAM engine.

I have just verified this has been fixed in both 3.51 and 5.1 recent releases.