MySQL Bugs: #27599: Driver crash on Connecting second time if another DBMS driver is connected

Bug #27599	Driver crash on Connecting second time if another DBMS driver is connected
Submitted:	2 Apr 2007 22:30	Modified:	19 Jun 2007 12:05
Reporter:	Farid Zidan (Candidate Quality Contributor)	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	Connector / ODBC	Severity:	S1 (Critical)
Version:	3.51.14	OS:	Windows (Windows XP)
Assigned to:	Bogdan Degtyariov	CPU Architecture:	Any

Description:
If application attempts to connect to non existing ODBC data source or application connects to a Firebird ODBC data source, subsequent attempts to connect to MySQL using ODBC connector results in sporadic crash.

How to repeat:
I am attaching a MS VC++ project the reproduce this crash.
1. Compile the project in MSVC++ 2005
2 Run the debug project
3 Substitute your DSN name and credentials at line 
const char *szConnect = "DSN=mysql;UID=root;PWD=root";

4 You can but don't have to create a Firebird ODBC data source to reproduce the crash
5 Application crashes the second time it tries to connect to MySQL

Suggested fix:
Environment handles/dbc handles getting mixed up?

Test project to reproduce connect crash

Attachment: TestDD.zip (application/x-zip-compressed, text), 52.04 KiB.

Thank you for the bug report. I was not able to extract the files from
the zip file attached with WinZip and Linux zip tool. Could you please
try to compress again and attach it?. Thanks in advance.

Same project but with legacy zip compression

Attachment: TestDD.zip (application/x-zip-compressed, text), 71.23 KiB.

More info:
1. If I first connect to Firebird using Firebird/interbase(r) driver MT ( 2.00.00.136 ) then subseqent attempt to connect to MySQL using ODBC/connector result in crash.

2 If I use the latest version of Firebird/interbase(r) driver ( 2.00.00.142 ) to conect first to Firebird, then no crash if I try to connect to MySQL using odbc connector.

Firebird ODBC driver have changed their dll name which is located in the system directory from odbcJdbcMT.dll to odbcfb32.dll between these two versions.

After uninstalling both Firebird ODBC drivers, MySQL driver crashes only if I run the test program from the Debugger after trying to connect to non-existing DSN

Latest version of Firebird ODBC driver can be loaded from here
http://www.praktik.km.ua/downloads/Firebird_ODBC_2.0.0-Win32.exe

Farid, thanks for your report and test case.

Can you tell me:
 - What ZIP are you using? 7-zip also has problems but at least I can see your test case.
 - Can we boil down this test case to most siplest one? I presume your problem is this: 
  - Try to conenct to non-existent DSN
  - Try to connect to existing DSN -> Crash.
Is that correct?

I am using WinZip 11.0 for the sample project, but the last zip I changed the compression method from the default to "Legacy zip 2.0".  I am attaching this project now as zip with no compression.

Very strange behavior. Basically,

1. connect to Firebird -> ok
2 connect to MySQL -> crash or ok
3 disconnect from MySQL
4 connect to MySQL ->crash

after step 2, driver crashes on subsequent connects to if I try to connect first to non-existing DSN.  Some DLLS or module is getting loaded in memory and is causing the crash and disconnecting from Firebird/shutting down MySQL server, does not help.

Sample project but no compression

Attachment: testDD_no_comppression.zip (application/x-zip-compressed, text), 195.15 KiB.

Farid, I have you project up and running *but* this is not the test case, this is your app and it seems to me you are calling for code review... I can't spend that much time examining your code, sorry. 

Can you boil down your app to simple test case (without firebird!) and comment in code:
  //put fake DSN here
  //put existing (valid) DSN here.
 - Remove reference to firebird. I don't have it and it's not MySQL product.
 - Make single file console test case (no menus, forms, boxes ...)

If MyODBC reconnects without using firebird driver first than I suggest it's possibly their problem. Ie. if "connect MyODBC fake DSN, connect MyODBC valid DSN" works then it's probably firebird problem.

Tori, that is already done in the test project. Ignore the rest of the code in the test project ( it does not get called ).  The test case is just one function call commented as you noted.  I have already included the string you need to look for in the original report, but here is more context:

		// to do: substitute your database connection info below
		ASSERT( FALSE );
		const char *szConnect = "DSN=mysql;UID=root;PWD=root";

My actual app always establishes a connection to a Firebird embedded database first, so that's an important part of the test case.  Without this part you will not be able to reproduce this issue.

Tori,

If you need any help setting up a Firebird data source to reproduce this issue, please let me know. I can help you set up such a data source, it will take about 15-20 minutes of your time.

Unfortunately, my app has to connect to Firebird at the start always ( cross-database app ), so ignoring Firebird connection is not an option.  None of the other drivers my app connects to crash, only MySQL ODBC driver.

Farid, I've never worked with Firebird and find it very time consuming and confusing when tried to set things up. Thus I made test with other ODBC drivers available on Windows by default. I tested MS Access driver and MS SQL server driver with this test case (no problems found):

#include <iostream>
#include <windows.h>
#include <sql.h>
#include <sqlext.h>
#include <stdio.h>

#ifndef TRUE
#define TRUE 1
#endif

#define MAXCOLS 100
#define MAX_DATA_LEN 255

SQLHENV  henv;
SQLHDBC  hdbc;
SQLHSTMT hstmt;

SQLINTEGER PrintError(SQLSMALLINT handleType, SQLHANDLE handle, SQLRETURN rcode)
{
    SQLRETURN rc = SQL_ERROR;
    SQLCHAR sqlState[6];
    SQLCHAR eMsg[SQL_MAX_MESSAGE_LENGTH];
    SQLINTEGER nError;
    SQLSMALLINT msgLen;
    
    if (rcode == SQL_NO_DATA)
    {
        std::cout << "NO DATA .. .. .." << std::endl;
        return(SQL_NO_DATA);
    }
    else
    {
        rc = SQLGetDiagRec(handleType, handle, 1, sqlState, &nError, eMsg, sizeof(eMsg), &msgLen);
        if (rc == SQL_SUCCESS || rc == SQL_SUCCESS_WITH_INFO)
        {
            std::cout << " Error: " << eMsg << std::endl;
        }
        return (SQL_ERROR);
    }
}

int main(int argc, char * argv[])
{
    SQLRETURN rc;
    argv[1] = "myodbc11"; //Non-existent DSN, real name is "myodbc1"
    argv[2] = "root";
    argv[3] = "";
// First try other ODBC drivers
    rc = SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
        return(PrintError(SQL_HANDLE_ENV, henv, rc));
    rc = SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, SQL_NTS);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
        return(PrintError(SQL_HANDLE_ENV, henv, rc));
    rc = SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
        return(PrintError(SQL_HANDLE_ENV, henv, rc));
    std::cout << "Connecting to " << "MS Access" << std::endl;
    rc = SQLConnect(hdbc, (SQLCHAR *)"MS Access Database", SQL_NTS, 
              (SQLCHAR *)"", SQL_NTS, 
              (SQLCHAR *)argv[3], SQL_NTS);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
        return(PrintError(SQL_HANDLE_DBC, hdbc, rc));
    rc = SQLDisconnect(hdbc);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
            return(PrintError(SQL_HANDLE_DBC, hdbc, rc));
    rc = SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
            return(PrintError(SQL_HANDLE_DBC, hdbc, rc));
    rc = SQLFreeHandle(SQL_HANDLE_ENV, henv);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
            return(PrintError(SQL_HANDLE_ENV, henv, rc));
//Now MyODBC 3.51.14GA with ERROR DSN first
    rc = SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
        return(PrintError(SQL_HANDLE_ENV, henv, rc));
    rc = SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, SQL_NTS);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
        return(PrintError(SQL_HANDLE_ENV, henv, rc));
    rc = SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
        return(PrintError(SQL_HANDLE_ENV, henv, rc));
    std::cout << "Connecting to bad DSN " << argv[1] << std::endl;
    rc = SQLConnect(hdbc, (SQLCHAR *)argv[1], SQL_NTS, 
              (SQLCHAR *)argv[2], SQL_NTS, 
              (SQLCHAR *)argv[3], SQL_NTS);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO) {
        std::cout << "Connecting to OK DSN " << "myodbc1" << std::endl;
	rc = SQLConnect(hdbc, (SQLCHAR *)"myodbc1", SQL_NTS, 
                  (SQLCHAR *)argv[2], SQL_NTS, 
                  (SQLCHAR *)argv[3], SQL_NTS);
	if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
	    return(PrintError(SQL_HANDLE_DBC, hdbc, rc));
	}
    rc = SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
        return(PrintError(SQL_HANDLE_DBC, hdbc, rc));
/*************************************************************************************/
    std::cout << "Connecting to OK DSN " << "running tests" << std::endl;
    SQLDOUBLE data;
    SQLINTEGER status;
    long n;
    rc = SQLExecDirect(hstmt, (SQLCHAR *)"USE test", SQL_NTS);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
        return(PrintError(SQL_HANDLE_STMT, hstmt, rc));
    rc = SQLExecDirect(hstmt, (SQLCHAR *)"DROP TABLE IF EXISTS mydec", SQL_NTS);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
        return(PrintError(SQL_HANDLE_STMT, hstmt, rc));
    rc = SQLExecDirect(hstmt, (SQLCHAR *)"CREATE TABLE `mydec` (`xdec` decimal(10,4)) ENGINE=MyISAM DEFAULT CHARSET=latin1", SQL_NTS);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
        return(PrintError(SQL_HANDLE_STMT, hstmt, rc));
    rc = SQLExecDirect(hstmt, (SQLCHAR *)"INSERT INTO mydec (xdec) VALUES (123456.4321)", SQL_NTS);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
        return(PrintError(SQL_HANDLE_STMT, hstmt, rc));
    rc = SQLExecDirect(hstmt, (SQLCHAR*)"select * from mydec", 19);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
        return(PrintError(SQL_HANDLE_STMT, hstmt, rc));
    rc = SQLFetch(hstmt);	
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
        return(PrintError(SQL_HANDLE_STMT, hstmt, rc));
    SQLINTEGER rs;
    SQLSMALLINT cl;
    SQLSMALLINT bl;
    SQLSMALLINT sLength;
    SQLSMALLINT sType;
    wchar_t pColName[255];
    unsigned long	lLength;   
    short	sScale;
    short uFlag;
    rc = SQLDescribeColW(hstmt, 1, (SQLWCHAR*)pColName,255,&sLength,	&sType,	&lLength,&sScale,&uFlag );
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
        return(PrintError(SQL_HANDLE_STMT, hstmt, rc));
    std::cout << "COL TYPE -> " << sType << std::endl;
    std::cout << "COL LENGTH -> " << lLength << std::endl;
    std::cout << "COL Scale -> " << sScale << std::endl;
    /*************************************************************************************/
    rc = SQLFreeHandle(SQL_HANDLE_STMT, hstmt);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
            return(PrintError(SQL_HANDLE_STMT, hstmt, rc));
    rc = SQLDisconnect(hdbc);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
            return(PrintError(SQL_HANDLE_DBC, hdbc, rc));
    rc = SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
            return(PrintError(SQL_HANDLE_DBC, hdbc, rc));
    rc = SQLFreeHandle(SQL_HANDLE_ENV, henv);
    if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO)
            return(PrintError(SQL_HANDLE_ENV, henv, rc));
    return(0);
}   

--Test output--
Connecting to MS Access
Connecting to bad DSN myodbc11
Connecting to OK DSN myodbc1
Connecting to OK DSN running tests
COL TYPE -> 3
COL LENGTH -> 10
COL Scale -> 4

Now you can try 3 things:
 - Review your code once more
 - Ask Firebird driver makers what in their (and only their) driver could cause this crash
 - Try other drivers (not Firebird) on your machine
and inform me of results.

Hi Tori,

I can help you set up a Firebird data source. It's very much like MS Access where the whole database is contained in one file.  No need to set up a server because I use the embedded FB client.  Like I said before it would take about 15-20 minutes of your time.

I don't understand why you are not using my test project. It has the test case with the right sequence of calls to create the crash.  In your test code you are doing something completely different like executing sql and describing resultset columns, etc, and that's not what I reported as causing the crash.  I know the driver works, this issue is strictly about the driver crashing on executing the call to CONNECT to the database the SECOND time around AFTER application connect to Firebird.  I am including the test case code from my project below, as you can see it is very simple and just few lines:

void CChildView::TestConnect() {

	SQLHENV     henvFB = NULL;    
	SQLHDBC     hdbcFB = NULL;
	SQLHSTMT    hstmtFB = NULL;

	// connect to Firebird
	// data source is not created on purpose to cause crash or you can create
	// a real firebird ODBC data source and you will also get a crash later trying
	// to connect to MySQL if you successfully connect to Firebird
	const char *szConnect = "DSN=fbembed;UID=SYSDBA;PWD=MASTERKEY";

	ASSERT( szConnect != NULL && *szConnect );

	SQLRETURN rc = Connect( henvFB, hdbcFB, szConnect );

	if ( !RC_SUCCESS( rc ) ) {

		DiagSQLError( henvFB, hdbcFB, hstmtFB, rc, "", "" );
	}

	const UINT cTryMax = 10;

	for ( UINT cTry = 0; cTry < cTryMax && hdbcFB != NULL; ++cTry ) {

		SQLHENV     henv = NULL;    
		SQLHDBC     hdbc = NULL;
		SQLHSTMT    hstmt = NULL;

		// to do: substitute your database connection info below
		ASSERT( FALSE );
		const char *szConnect = "DSN=mysql;UID=root;PWD=root";

		ASSERT( szConnect != NULL && *szConnect );

		SQLRETURN rc = Connect( henv, hdbc, szConnect );

		if ( !RC_SUCCESS( rc ) ) {

			DiagSQLError( henv, hdbc, hstmt, rc, "", "" );
		}
		else {

			// successfully connected to database

			rc = SetAutoCommit( hdbc, false );

			if ( !RC_SUCCESS( rc ) )
				DiagSQLError( henv, hdbc, hstmt, rc, "", "" );

			const bool bCommitOnDisconnect = false;

			rc = ::SQLTransact( henv, hdbc, 
					bCommitOnDisconnect ? SQL_COMMIT : SQL_ROLLBACK );

			if ( !RC_SUCCESS( rc ) )
				DiagSQLError( henv, hdbc, hstmt, rc, "", "" );
		}

		if ( hdbc != NULL )
			Disconnect( henv, hdbc );

		if ( henv != NULL )
			SQLFreeHandle( SQL_HANDLE_ENV, henv );

		if ( !RC_SUCCESS( rc ) )
			break;
	}

	if ( hdbcFB != NULL )
		Disconnect( henvFB, hdbcFB );

	if ( henvFB != NULL )
		SQLFreeHandle( SQL_HANDLE_ENV, henvFB );

}

Hi Tori,

Here is a step by step sequence for creating a Firebird data source and reproducing this issue:

1. Download Firebird embedded client 2.01
http://prdownloads.sourceforge.net/firebird/Firebird-2.0.1.12855-1_embed_win32.zip

2 Unzip the downloaded file into c:\FB_201

3 Download Firebird ODBC driver 2.00.00.142
http://www.praktik.km.ua/downloads/Firebird_ODBC_2.0.0-Win32.exe

4 Double-click on the downloaded file to install the Firebird ODBC driver

5 Download blank Firebird database file
http://www.zidsoft.com/Download/TEST.FDB

6 Move the downloaded database file to c:\FB_201

7 create a new Firebird ODBC data source using Windows Control panel ODBC Administrator. 
Use the following info:

Driver: Firebird/Interbase(r) driver ( 2.00.00.142 )
Data Source Name: fbtest
Database: C:\fb_201\test.fdb
Client: C:\fb_201\fbembed.dll
Database Account: SYSDBA
Password: masterkey

Click on the Test Connection button in the dialog to test connect to the data source and then hit ok

8 In the test MS VC++ project locate void CChildView::TestConnect() and replace the Firebird DSN connect string
DSN name from 'fbembed' to 'fbtest' ( the Firebird DSN name you created above in step 7 ):
const char *szConnect = "DSN=fbembed;UID=SYSDBA;PWD=MASTERKEY";

9 Few lines below change the MySQL connect string as necessary for connecting to your MySQL database:
ASSERT( FALSE );
const char *szConnect = "DSN=mysql;UID=root;PWD=root";

10 compile and run the project

11 from the Test Menu, click run Test.

12 You should crash at this time, if not, exit app and run it again

13 You should at least get some assert errors when the MySQL driver is trying to connect, usually those result in a crash but you could be lucky and not crash

Farid, thanks for extensive fb tutorial. Just what I needed.

Now, I run your test numerous times, following your instructions, on:
 - MySQL server 5.0.38BK on WinXP Pro SP2 localhost
 - MyODBC 3.51.14 GA
 - VS2005 Pro
 - Exact FB ODBC driver
 - Exact FB embedded server (cut from changelog so we can match versions)
  **************************
  * v2.0.1
  **************************
    * Improvement CORE-1071
        Background garbage collector doesn't need to read backversions
        of the active record
      Contributor(s):
        Vlad Horsun <horsun at kdb.dp.ua>
    * Improvement CORE-1047
        Add support for Gentoo/FreeBSD detection
      Contributor(s):
        Alex Peshkov <peshkoff at mail.ru>

No problem occur! Look at my server log:
070405 17:58:45	     14 Connect     root@localhost on test
		     14 Query       SET SQL_AUTO_IS_NULL=0
		     14 Query       SET AUTOCOMMIT=0
		     14 Query       ROLLBACK
		     14 Quit       
		     15 Connect     root@localhost on test
		     15 Query       SET SQL_AUTO_IS_NULL=0
		     15 Query       SET AUTOCOMMIT=0
		     15 Query       ROLLBACK
		     15 Quit       
		     16 Connect     root@localhost on test
		     16 Query       SET SQL_AUTO_IS_NULL=0
		     16 Query       SET AUTOCOMMIT=0
		     16 Query       ROLLBACK
		     16 Quit       
		     17 Connect     root@localhost on test
		     17 Query       SET SQL_AUTO_IS_NULL=0
		     17 Query       SET AUTOCOMMIT=0
		     17 Query       ROLLBACK
		     17 Quit       
		     18 Connect     root@localhost on test
		     18 Query       SET SQL_AUTO_IS_NULL=0
		     18 Query       SET AUTOCOMMIT=0
		     18 Query       ROLLBACK
		     18 Quit       
		     19 Connect     root@localhost on test
		     19 Query       SET SQL_AUTO_IS_NULL=0
		     19 Query       SET AUTOCOMMIT=0
		     19 Query       ROLLBACK
		     19 Quit       
		     20 Connect     root@localhost on test
		     20 Query       SET SQL_AUTO_IS_NULL=0
		     20 Query       SET AUTOCOMMIT=0
		     20 Query       ROLLBACK
		     20 Quit       

Later, I even tried with what I think is closer to the problem, by my opinion:
	if (cTry == 0) {
	  char *szConnect = "DSN=myodbc11;UID=root;PWD="; //FAKE DSN
	}
	else {
	  char *szConnect = "DSN=myodbc1;UID=root;PWD="; //REAL DSN
	}
everything works.

Now it's your turn to test if you want to find out more. What happens if you run your test case with pageheap (gflags /p) in debugger (http://technet2.microsoft.com/WindowsServer/en/library/00d4872f-eeb3-4a6e-910a-299ad55aed6...)?

Hi Tori,

I am afraid I have to find a better test case, as this test case is not crashing all the time.  But once it does, it crashes most of the time after that.

Using gflags.exe -p /enable cmpdata.exe
with my application that is crashing on connecting to MySQL ( executing the SQLConnect call ), I get the following error message:
Title: ODBC Administrator
Message Text: Unable to obtain memory. Please exit immediately

Next I may not crash but if I repeat this enough, then I crash and once that happens I don't get this message anymore before all connects that all result in crashes

After this if I use the test project I get the following error message
Title: <blank>
SQLState: HY000
Native Error: 0
[MySQL][ODBC 3.51 Driver]Could not determine the driver name;could not lookup setup library. DSN=(...)

Even though the DSN is still there. Other time it just crash.

Tori,

My actual app uses version 2.0 of the Firebird client and MySQL driver seems to crash more with that.  You can download and run my actual app from here
http://www.zidsoft.com/Download/cmpdata_1.3.7.95.msi

It automatically installs and uses an Firebird ODBC driver version 2.00.00.136
To test this crash with my app:
1. After downloading and installing CompareData app, use Tools |Data sources menu to add the MySQL ODBC data source to the application

2 On creating the application data source for the MySQL ODBC data source, the app automatically tests connecting to the data source ( you may or may not crash at this time )

3 Choose Edit to open up the data source setup window again and click OK to test  connecting to the MySQL data source again

4 if you repeat step 3 a number of times, then you will crash
5 after that all subsequent attempts to connect to MySQL using MySQL ODBC driver from the app or the test project will crash

Faarid, this doesn't tell me much except that some things in Firebird ODBC driver got fixed in newer release... However I will try to help find the solution.

Now, I would like you to attach ODBC driver trace (DM, Tracing, Machine wide tracing...) from the moment your app started till the crash occur.

Tori,

The Firebird ODBC driver does not crash.  The app crashes calling SQLConnect to connect to the MySQL data source using the MySQL ODBC driver after the Firebird connection is established.  I am just guessing here but looks like a memory allocation is failing the first time around ( no crash ) that is not getting caught and its data is getting cached, on subsequent attempts to connect ( second time around and thereafter ) driver is using the invalid cached data?

Turned on the Trace Driver Calls checkbox in the Debug tab of the DSN setup dialog, but no file is getting created on the crash ( no c:\myodbc.log file ).

Farid, you make me repeat myself. Please read, word by word, my last post:

"Farid, this doesn't tell me much except that some things in Firebird
ODBC driver got fixed in newer release..."
- I don't see FB crashing mentioned anywhere, do you? Please don't put words in my mouth.

"However I will try to help find the solution."
- Yes I will, even though you're not reporting this to FB support which I think you should.

"Now, I would like you to attach ODBC driver trace (DM, Tracing, Machine
wide tracing...) from the moment your app started till the crash occur."
- Nobody mentioned "Trace Driver Calls checkbox in the Debug tab"! Please do as asked. DM/Tracing/"Machine wide tracing" checkbox.

And, for the sake of argument, please try somebody elses driver, not ours, in this test and see if it breaks too.

Tori,

I misread your words, as you can see I attached the file you "requested."  For your information my app is tested with over 40 different drivers. Let me repeat that: Forty different drivers and DBMSs and none of them crashes connecting to the database.   

I understand it's not easy writing drivers, but I am trying as much as I can to present the information to you.  Don't know what you mean by reporting this to Firebird. Their driver is not crashing. I have been using it for over two years now and not a SINGLE crash.

You may find it more productive to focus on the issue at hand, like an engineer, rather than shooting the messenger or picking up on words. That would be more of a professional and constructive approach.

By the way, I am all for free-spirited development, but that also means having respect for the people around you.  Something you have not shown much of in this case.

Farid, let me try to answer you even though you have taken this to personal level...

- On the report, generally:
1) We always ask for small but complete standalone test case exhibiting the problem every time it is run. I got application which means I need to do code review to figure out what's going on before any real job is done. This is disrespectful to me and other reporters. Please see my test case and compare it with yours. Imagine yourself in my place trying to figure out some application landed before you.

2) You posted two archives which we were unable to unpack, even though I use 7-zip 4.43, taking our time and filling up bugsdb.

3) It was not until your last post that I was given complete picture of problem and detailed steps on how to reproduce it. It should have been there right from the start. Please take a look at http://bugs.mysql.com/bug.php?id=27668 for example. Let's consider you *last* post, two parts in particular:
Part 1: For your information my app is tested with over 40 different drivers.
Part 2: Don't know what you mean by reporting this to Firebird.
If I was to know Part 1 from the beginning there would be no need for Part 2. But as I said, report was uncomplete until the last post.

- On the *respect*:
1) Taken in account all I said before and the fact *your* test case works on my machine (!) I'm stil giving you a chance and follow this conversation closely.

2) You do not know what's happening behind the scenes. You disregard the option that I might have already escalated this problem to our top ODBC devs, like I did last night, and focus on what I said trying to extract every bit of relevant info I could (due to lack of it in your report). We care about you and we care about quality of our products!

3) You made me repeat myself and disregard my questions/requests for many times. I'll get to this later.

4) My name is Tonci which is form of Tony. Even Anthony will pass but not "Tori" :)

- On the professionalism:
1) Please, boil *down* your test case to a simple standalone test exhibiting this error.

2) Please conduct tests I asked for. Your's is the only environment showing this crash so far. If you don't do it I don't know who will:
Test 1: Use other drivers instead of ours, in the same place, and try:
Load FB ODBC drv
Load Access ODBC drv (and one or two others)
Do tests
so we can establish that only MyODBC exhibits this problem.

- Conclusion:
1) This report must stay in "Can't repeat" until test case failing, at least on my machine, is written. This is not personal! I *can't fix* what I *don't see*. So *focusing* on "real" problem will wait until such time and it completely depends on you.

2) I am stil puzzled with "My actual app uses version 2.0 of the Firebird client and MySQL driver seems to crash more with that." statement. How come it's our bug if using newer FB software fixes it? Please contact FB support and clear this out for me.

3) If you can tell me how is it possible for you to miss that
- I'm working on a problem I'm not able to repeat and that's reported by only one community member, namely you.
- I have spent hours on this report which I can't justify to my boss in any way.
- I'm trying to help you bring us to repeatable test case ...
and I'm still accused of "disrespect" and "unprofessionalism"? Please remove this from personal level. You have set this report to "Critical" so I now it's grave for you but that doesn't justify your last post. Writing in that manner only delays finding of solution.

We care about our community. Thanks for your interest in MySQL.

Tonci,
Sorry about misspelling your name.  If you had alerted me to this earlier, I would have been quicker to see that.

When trying to reproduce a specific crash you have to test as close as possible to the situation the crash is reported in as much is possible.  

I have included info about how this crash happens with my actual app and included step-by-step instructions on how to reproduce this using my actual app in a previous post.  Please see if you can reproduce the crash using those steps.

I can reproduce the crash easily using that scenario and in combination with the test project.

Tonci,

I would like you to escalate this issue to your boss. I am very unhappy with the unprofessional attitude you presented to me and anybody reading this. I do not take your attitude and lack of professionalism as a statement about the MySQL project. As far as I am concerned, you represented yourself only.

1. When someone gives you a project with a test case of about 10 lines of code that merely attempts to connect to the database and explicitly tells you ( step 3 of my first report ) what line to look for to change to connect to the database, you should not feel say that they are asking for a code review of their application. That's not helpful.

2. When trying to reproduce a bug, you should follow the instructions as reported on how to reproduce the bug. Writing a completely different test case with different api calls is not the reported issue.

3. Never tell a customer "do as asked", that's not an attitude that helps cooperation. Try, ".. can you..", "..would you", that would be less abrasive.

4. When trying to diagnose a problem, try your best to go the next step yourself instead of bouncing back at the customer. I have used WinZip from my Windows XP machine to zip the test project. I was sorry your workstation zip program is not up-to-date and was more than accommodating to dumb down my WinZip all the way to no compression to help accommodate you. Instead what I got is criticism because your workstation zip program is not up-to-date.

5.The customer is not the enemy. Instead of picking on and flaming the customer, try to focus on the information and issue at hand. You are not "winning" by belittling the customer and using abusive communication.

To conclude, I am very unhappy with the level of your technical skills and professionalism. Have you spent more time trying to reproduce the problem than engaging in petty arguments and words, we may have had a better chance of resolving this issue.

Tested new 3.51.15 driver and still able to reproduce the crash with my app. On further testing I completely factored out Firebird ODBC driver connection. This crash also happens if a database connection is established first to Oracle or MS SQL Server Express, for example.

Overview:
- Connect to Firebird or MS SQL Express or Oracle ( application repository connection )
- open a MySQL dbms comparison
- close MySQL dbms comparison
- connect to MySQl -> Crash

Dear Farid,

Thank you for the feedback and the whole effort you are spending
in to help us to resolve this issue. I would like to express you
my apologies if in someway we aren't handled it adequately so far,
however I asked for my co-worker to try to test it as soon as possible.
Again thank you for your help.

Farid,

I was able to build and run your test project. Here is a brief summary of what I found when debugging MyODBC driver and MFC application:

 - TestDD throws an error message:
   "This may be due to a corruption of the heap, and 
   indicates a bug in TestDD.exe or any of the DLLs it has loaded.".
   
   This happens only when use the driver prompt which means that neither DSN
   nor connection string have no correct login/password. In this case the driver 
   displays the GUI prompt that can cause crash.

 - If the login and password in the connection string are ok the crash does not 
   occur.

The problem with the GUI prompt has just been fixed.
Could you let me know whether you had crashes only when GUI driver prompt is displayed or the crashes appeared in any case (even with SQL_DRIVER_NOPROMPT connection option for SQLDriverConnect)?

Hi Bogdan,

My application always uses SQL_DRIVER_COMPLETE with SQLDriverConnect to connect to the database. The logid and password are correctly supplied and the first connection to MySQL succeeds. However, the crash happens later when I try to establish a second connection ( using the same connect string ).

I was hoping the test project would isolate the crash, but it does not reliably do so. I was just able to duplicate the crash using my application by trying to establish connections repeated few times. In order to use this sequence you need to download my app and install it. Here is the sequence I used that resulted in the same crash:

1. Download app from http://www.zidsoft.com/Download/cmpdata.msi and install it
2. The application automatically connects to its Firebird repository when it starts
3. Add an ODBC data source for a MySQL database to the application ( Tools | Data Sources ) and call it MySQL1
4 Add another application data source for the same MySQL ODBC DSN and call it MySQL_copy
4 Add a DBMS comparison for the MySQL1 data source to itself.
6 Open Data sources dialog ( Tools | Data sources ) and click Edit to edit MySQL_copy data source
7 You don't need to edit anything, just click OK button to test connecting to MySQL_copy
8 close the dialog
5 Right click on the added MySQL1 DBMS comparison in the tree and choose option to close it ( disconnects )
6 Open Data Sources dialog ( Tools | Data Sources ) and select the MySQL1 data source ( or MySQL_copy ) and do Edit to test connecting to data source
7 Crash

You may have to re-open/close the tree DBMS comparison item a couple of time and do Edit to the data source a number of times for the crash to happen

Once the crash happens the first time, it will happen more often subsequently.

If you are still unable to duplicate the crash, maybe we can use Windows XP messenger to have you view my pc so you can view how I duplicate the crash. My Windows Messenger ID is farid@zidsoft.com

Regards

Farid,

Thanks for the detailed instructions. However, although I followed them carefully, the crash did not happen. I made several attempts in order to repeat the problem and rolled back the version of myodbc to 3.51.14 then 3.51.12 without any success.

Here is the log from CompareData (DSN name is test4):
---------------------
Connecting to <Embedded Repository>
successfully connected to <Embedded Repository>
Ready
Testing connection to test4
[Warning] Driver Row Bind Offset Support
Driver does not support row bindoffsets.  Data source 'test4'
successfully connected. Disconnecting
Testing connection to test4
[Warning] Driver Row Bind Offset Support
Driver does not support row bindoffsets.  Data source 'test4'
successfully connected. Disconnecting
Connecting to MySQL1
[Warning] Driver Row Bind Offset Support
Driver does not support row bindoffsets.  Data source 'MySQL1'
successfully connected to MySQL1
Loading MySQL1
Opening MySQL1 items ( hold Shift Key to stop )
Connecting to <Embedded Repository>
successfully connected to <Embedded Repository>
Testing connection to test4
[Warning] Driver Row Bind Offset Support
Driver does not support row bindoffsets.  Data source 'test4'
successfully connected. Disconnecting
Testing connection to test4
[Warning] Driver Row Bind Offset Support
Driver does not support row bindoffsets.  Data source 'test4'
successfully connected. Disconnecting
---------------------
Can you look at it perhaps I missed some important step...
Meanwhile I'll try it on 32-bit version of WinXP SP2 (Current tests were performed on 64-bit WinXP SP2 ).

Hi Bogdan,

I am running Windows XP 32-bit SP2, so maybe that's a factor. I don't see any thing missing from your log, you seem to open/close the dbms comparison and connect by editing the data source successfully. On my setup repeating that is a good way of inducing the crash.

Farid,

Unfortunately, my tests on 32-bit version of WindowsXP were unsuccessful.
I added your ID to my Windows Messenger contacts. As I usually don't keep WinMessanger running all the time on my machine, please write me an email when you are ready to demonstrate the crash on your PC.

Hi Bogdan,

Ok, let's try to connect using Windows Messenger. Can you give my your Messenger ID so I can add to my contacts. You can email me directly farid@zidsoft.com
I have Windows Messenger now running.

Farid,

as the pre-release version of myodbc driver does not solve your problem I will make a debug build which allows to see more information about the crash.

Farid,

I have uploaded a debug version of the driver with the program debugging database to our FTP:


ftp://ftp.mysql.com/pub/mysql/hidden/connectors/odbc/myodbc-3.51.16-rc-win32-debug-pdb.zip

In order to have the program database available for Visual Studio debugger you need to copy all files including *.pdb and *.map into WINDOWS\SYSTEM32 directory. When the application crashes, please select debugging and then send me the stack trace with the function names and source code line numbers where the error occured.
Thanks.

Hi Bogdan,

Below is the information I got after the crash with new debug version of the driver.

Regards,
Farid

Stack info from the debugger after the crash:

 	odbccp32.dll!5fe8dcff() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for odbccp32.dll]	
 	ntdll.dll!7c9106eb() 	
 	msvcrt.dll!77c2c1db() 	
 	kernel32.dll!7c809d75() 	
 	msvcrt.dll!77c2c215() 	
 	odbccp32.dll!5fe8ddef() 	
 	odbccp32.dll!5fe938db() 	
 	myodbc3.dll!MYODBCUtilReadDataSource(tMYODBCUTIL_DATASOURCE * pDataSource=0x02285028, const char * pszDSN=0x001de780)  Line 262 + 0x1f bytes	C
 	myodbc3.dll!my_SQLDriverConnect(void * hdbc=0x00249898, HWND__ * hwnd=0x005c052c, unsigned char * szConnStrIn=0x00f43fd8, short cbConnStrIn=-3, unsigned char * szConnStrOut=0x00f44038, short cbConnStrOutMax=1024, short * pcbConnStrOut=0x0012f0f4, unsigned short fDriverCompletion=1)  Line 427 + 0x10 bytes	C
 	myodbc3.dll!SQLDriverConnect(void * hdbc=0x00249898, HWND__ * hwnd=0x005c052c, unsigned char * szConnStrIn=0x00f43fd8, short cbConnStrIn=-3, unsigned char * szConnStrOut=0x00f44038, short cbConnStrOutMax=1024, short * pcbConnStrOut=0x0012f0f4, unsigned short fDriverCompletion=1)  Line 737 + 0x2f bytes	C
 	odbc32.dll!7434b2f5() 	
 	odbc32.dll!74323079() 	
 	odbc32.dll!74322fbc() 	
 	ntdll.dll!7c91056d() 	
 	advapi32.dll!77dd797e() 	
 	advapi32.dll!77dd7883() 	
 	ntdll.dll!7c90d592() 	
 	advapi32.dll!77dd6bcc() 	
>	mfc80.dll!ATL::CSimpleStringT<char,1>::CloneData(ATL::CStringData * pData=0x0012fad4)  Line 891	C++
 	advapi32.dll!77dd7883() 	
 	mfc80.dll!ATL::CSimpleStringT<char,1>::CSimpleStringT<char,1>(const ATL::CSimpleStringT<char,1> & strSrc=<Bad Ptr>)  Line 242	C++
 	mfc80.dll!CWinApp::GetProfileStringA(const char * lpszSection=, const char * lpszEntry=, const char * lpszDefault=)  Line 153 + 0xe bytes	C++
 	mfc80.dll!ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >::operator=(const ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > & strSrc="‹T$Bð‹Jì3ÈèîÖÿÿ¸\^I")  Line 1267	C++
 	cmpdcom.dll!0046bf2c() 	
 	cmpdcom.dll!0046cddf() 	
 	cmpdcom.dll!0046cdeb() 	
 	cmpdcmp.dll!006b2388() 	
 	cmpdmn.dll!0078a5f6() 	
 	cmpdmn.dll!007d22dd() 	
 	cmpdmn.dll!007aad4f() 	
 	mfc80.dll!_AfxDispatchCmdMsg(CCmdTarget * pTarget=0x00000000, unsigned int nID=749, int nCode=1244064, void (void)* pfn=0x00000000, void * pExtra=0x00000000, unsigned int nSig=56, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000)  Line 82	C++
 	mfc80.dll!CCmdTarget::OnCmdMsg(unsigned int nID=749, int nCode=0, void * pExtra=0x00000000, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000)  Line 381 + 0x16 bytes	C++
 	cmpdmn.dll!007ce778() 	
 	mfc80.dll!CThreadLocalObject::GetData(CNoTrackObject * (void)* pfnCreateObject=0x000002ed)  Line 430 + 0x5 bytes	C++
 	mfc80.dll!CWnd::OnCommand(unsigned int wParam=0, long lParam=0)  Line 2299 + 0xd bytes	C++
 	mfc80.dll!CFrameWnd::OnCommand(unsigned int wParam=749, long lParam=0)  Line 321 + 0xf bytes	C++
 	mfc80.dll!CWnd::OnWndMsg(unsigned int message=273, unsigned int wParam=749, long lParam=0, long * pResult=0x0012fd1c)  Line 1755 + 0x10 bytes	C++
 	mfc80.dll!CWnd::WindowProc(unsigned int message=273, unsigned int wParam=749, long lParam=0)  Line 1741 + 0x17 bytes	C++
 	mfc80.dll!AfxCallWndProc(CWnd * pWnd=0x00000000, HWND__ * hWnd=0x005c052c, unsigned int nMsg=273, unsigned int wParam=749, long lParam=0)  Line 243	C++
 	mfc80.dll!AfxWndProc(HWND__ * hWnd=0x005c052c, unsigned int nMsg=273, unsigned int wParam=749, long lParam=0)  Line 388 + 0x10 bytes	C++
 	mfc80.dll!AfxWndProcBase(HWND__ * hWnd=0x005c052c, unsigned int nMsg=273, unsigned int wParam=749, long lParam=0)  Line 411 + 0x16 bytes	C++
 	user32.dll!7e418734() 	
 	user32.dll!7e418816() 	
 	mfc80.dll!CThreadSlotData::GetThreadValue(int nSlot=0)  Line 265	C++
 	user32.dll!7e4189cd() 	
 	mfc80.dll!CWnd::FromHandle(HWND__ * hWnd=0x0015a248)  Line 311	C++
 	user32.dll!7e4196c7() 	
 	mfc80.dll!AfxInternalPumpMessage()  Line 183	C++
 	mfc80.dll!CWinThread::Run()  Line 625 + 0x7 bytes	C++
 	mfc80.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00152349, int nCmdShow=1)  Line 47 + 0x7 bytes	C++
 	cmpdata.exe!00406dbf() 	
 	kernel32.dll!7c816fd7() 	

Here is where the debugger stops in the source code ( file atlsimpstr.h line 891 )
	static CStringData* __cdecl CloneData( __in CStringData* pData )
	{
		CStringData* pNewData = NULL;

		IAtlStringMgr* pNewStringMgr = pData->pStringMgr->Clone();
------>		if( !pData->IsLocked() && (pNewStringMgr == pData->pStringMgr) )
		{
			pNewData = pData;
			pNewData->AddRef();
		}

Here is copy of the debugger threads view:
>	4736	SQLDriverConnect	MYODBCUtilReadDataSource	Above Normal	0
 	5908	Win32 Thread	7c90eb94	Normal	0
 	132	Win32 Thread	7c90eb94	Normal	0
 	5900	free	free	Normal	0
 	5968	Win32 Thread	7c90eb94	Normal	0
 	4648	_DllMainCRTStartup	_free_dbg_lk	Normal	0

I am attaching copy of loaded modules in a separate file.

The place where this is crashing is interesting, because it is in a part of the MYODBCUtilReadDataSource() function that is supposed to be a work-around for a bug in SQLGetPrivateProfileString() on Windows XP.

In fact, it might be this issue: http://support.microsoft.com/kb/909122/

odbccp32.dll on machine is version 3.525.1117.0 (xpsp_sp2_rtm.040803-2158)
So my machine does not have the hotfix for the MS issue. It seems that you have to log a support issue to MS to get the hotfix.

I do have a large number of both user and system DSNs defined on my machine ( around 140 )

My version of odbccp32.dll is 3.526.2825.0. That is a possible reason why I was unable to reproduce the crash on my machine.

Very possible if that's the cause of the crash. Please note that my machine is up to date as far as Windows updates ( automatic updates ). The MS hotfix version of odbccp32.dll is only obtainable by calling Microsoft and logging a support issue.

After replacing odbccp32.dll with version 3.526.2825.0, I am no longer able to reproduce the crash. I will have test more, but right now it appears that the crash is gone. Also, gone is crash connecting to MySQL where server is not running.

Thank you all for helping to identify this issue.

We should document this issue in order to avoid such situations in future bug reports.