Bug #4704 unicode app + multiple threads + odbc = app crash
Submitted: 22 Jul 2004 18:10 Modified: 30 May 2013 11:54
Reporter: S Lopes Email Updates:
Status: Can't repeat Impact on me:
None 
Category:Connector / ODBC Severity:S2 (Serious)
Version:3.51.08 OS:Windows (Windows 2000 Pro)
Assigned to: CPU Architecture:Any

[22 Jul 2004 18:10] S Lopes
Description:
MySQL Server 4.1.1 alpha
MyODBC Connector: 3.51.08

I am experiencing the following problem: I have an dialog-based MFC app using the CDatabase class to connect to a MySQL DB using ODBC. My connection string specifies a DSN with the connection information. Additionally, this is a Unicode compilation ( Project Properties > General > Use Unicode Character Set ). My test app has a CWinThread-derived class named CDBThread, with a CDatabase member. CDBThread::InitInstance() calls OpenEx() for the CDatabase member. So far so good.

For the app's InitInstance, all I do is call AfxBeginThread() twice, to create two threads of type CDBThread. The application crashes when the db thread tries to connect to the db.

However, there are two things I can do to avoid the crash:

- Start only ONE CDBThread instead of TWO.
- Compile using multi-byte character set instead of Unicode.

Of course, these are both unnaceptable solutions. But it seems the problem is related only to multi-threaded apps using Unicode. Each CDBThread has its own CDatabase object, so no additional synchronization should be needed as two separate db connections should be created, right?

Oh, yeah, I tried replacing the MySQL db with an MS Access db and the problem went away.

Here's the stack at the time of the crash. I don't see myodbc3.dll on the stack, but again, the problem did not occur with MS Access.

 	odbc32.dll!1f7b7e08() 	
 	odbc32.dll!1f7b8cd1() 	
 	odbc32.dll!1f7c59b8() 	
 	odbc32.dll!1f7a2f84() 	
 	odbc32.dll!1f7a2cb8() 	
 	msvcrt.dll!___updatetlocinfo()  + 0x40	
 	NTDLL.DLL!_RtlpAllocateDebugInfo@0()  + 0x67	
 	NTDLL.DLL!_RtlInitializeCriticalSection@4()  + 0xb	
 	KERNEL32.DLL!_InitializeCriticalSection@4()  + 0xa	
 	NTDLL.DLL!_RtlDebugAllocateHeap@12()  + 0x2bf	
 	NTDLL.DLL!_RtlAllocateHeapSlowly@12()  + 0x1a250	
 	NTDLL.DLL!_RtlAllocateHeap@12()  + 0x8f4	
 	NTDLL.DLL!_LdrpGetProcedureAddress@20()  + 0x144	
 	KERNEL32.DLL!_GetProcAddress@8()  + 0x3c	
>	mfc71ud.dll!CWnd::GetActiveWindow()  Line 193 + 0xf	C++

// From my db thread class:
BOOL CDBThread::InitInstance()
{

	m_db.OpenEx( _T( "ODBC;DRIVER=MySQL ODBC 3.51 Driver;DSN=dbtest;" ) );
	return TRUE;
}

// From the main app:
BOOL CDbtestApp::InitInstance()
{
	// (...) MFC wizard stuff here

	m_Thread[ 0 ] = AfxBeginThread( RUNTIME_CLASS( CDBThread ) );

	// Comment out the line below and no more crashes.
	m_Thread[ 1 ] = AfxBeginThread( RUNTIME_CLASS( CDBThread ) );

	// (...) more MFC wizard stuff here
}

Thank you,

Silvio Lopes de Oliveira
Software Engineer

How to repeat:
See code sample under "Description"
[1 Sep 2004 3:24] MySQL Verification Team
Could you please provide us with a complete test case, the dsp file
the better. If you want to preserve the privacy of your code you
can select in the Files tab the option for only MySQL developers
to have access or upload the file at:

ftp://ftp.mysql.com:/pub/mysql/upload

making reference in the zip file name this number bug report.

Thanks in advance.
[9 Sep 2004 17:16] S Lopes
I've uploaded a test case for this bug. The file name is "Bug #4704 - Test Case UPDATED.zip". Note that there is another file for this bug, which is missing the SQL script to create the test db. Make sure to get the file whose name says "UPDATED".

This problem was experienced when compiling with VC++ .NET 2003; as such, I did not include any VC++ 6.0 project files.

Please read README.TXT for instructions on how to set up the data source.

S Lopes
[21 Oct 2004 15:38] S Lopes
Simple Visual C++ project which recreates the problem + db script for creating the db

Attachment: Bug #4704 - Test Case UPDATED.zip (application/x-zip-compressed, text), 25.80 KiB.

[22 Oct 2004 7:09] Sébastien FELDIS
I have the same problem in Release mode of a multithreaded UNICODE MFC application. The call of CDatabase::OpenEx overwrites memory of my application near the call of CDatabase::OpenEx leading to an access violation.

Using MBCS instead of UNICODE solves the problem.
Using the same application with SQLServer, Centura or Access works.

My development environnement is the following :

- Windows XP SP1
- MySQL Server 4.0.18 max-debug
- MyODBC Connector 2.50.39, 3.51.6 and 3.51.9
- Visual Studio .NET 2002
- UNICODE app
- Release mode
- A thread provides database support to an other thread.

Details :

My application uses a DLL (called DLL1) which wants database support.
DLL1 calls an other DLL (called DLL2) which provides the database support...

If DLL2 call OpenEx to get the data that DLL1 needs I get an access violation !
But if DLL2 gives a pointer to CDatabase to DLL1 and DLL1 calls OpenEx in the function or class where you want to use it there is no problem (calling OpenEx in a helper function which only does the job of opening the database does not work, so I inlined this function and everything seems to work fine).

Sébastien FELDIS
[25 Oct 2004 8:58] Sébastien FELDIS
The fix from my last comment doesn't work in all cases.
[14 Feb 2005 22:54] Bugs System
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".
[30 May 2013 11:54] Bogdan Degtyariov
Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.mysql.com/how-to-report.php

If you can provide more information, feel free to add it to this bug and change the status back to 'Open'.

Thank you for your interest in MySQL.