[ODBC-280] Process crashes after some time Created: 2020-04-21  Updated: 2020-06-30  Resolved: 2020-04-26

Status: Closed
Project: MariaDB Connector/ODBC
Component/s: General
Affects Version/s: 3.1.7
Fix Version/s: 3.1.9

Type: Bug Priority: Major
Reporter: Matthias Rauber Assignee: Lawrin Novitsky
Resolution: Fixed Votes: 0
Labels: None
Environment:

Windows Server 2019 Datacenter; MariaDB Server 10.3 x64


Attachments: File maodbc.dll     PNG File screenshot-1.png    
Issue Links:
Duplicate
duplicates ODBC-275 Faults after some time Closed

 Description   

Similiar to odbc-275 the process using the odbc driver crashes after some time
(mostly while idling) with only the following output dumped in the event log:

Name der fehlerhaften Anwendung: #########, Version: 0.1.0.0, Zeitstempel: 0x5e9d5491
Name des fehlerhaften Moduls: maodbc.dll, Version: 3.1.7.0, Zeitstempel: 0x5e8ce4bc
Ausnahmecode: 0xc0000409
Fehleroffset: 0x000a119f
ID des fehlerhaften Prozesses: 0x1658
Startzeit der fehlerhaften Anwendung: 0x01d6171314a8a0f3
Pfad der fehlerhaften Anwendung: C:\Users\########\Desktop\Local\#########
Pfad des fehlerhaften Moduls: C:\Program Files (x86)\MariaDB\MariaDB ODBC Driver\maodbc.dll
Berichtskennung: 06c71983-5062-4674-8934-29d5d32041c1

followed by a mysql warning entry with the text similiar to:

Aborted connection xxxx to db: '#########' user: '############' host: 'localhost' (Got an error reading communication packets)

Contrary to the linked issue, my connection string already contains the full ip adress of the host (127.0.0.1 on the current configuration). I could not reproduce the issue on our old Windows Server 2012 development machine.



 Comments   
Comment by Lawrin Novitsky [ 2020-04-21 ]

Thank you for your report.

Would it be possible to get a dump or at least a stacktrace for this crash?

Do you have auto reconnect enabled? and if no, would it work around the issue?

Comment by Matthias Rauber [ 2020-04-21 ]

Some further information:
The issue can be resolved (or mitigated) if i enable connection pooling.

The exact exception message is the following

Unhandled exception at 0x6F59119F (maodbc.dll) : An invalid parameter was passed to a function that considers invalid parameters fatal. 

Following a stacktrace:

 	maodbc.dll!_invoke_watson(const wchar_t * expression, const wchar_t * function_name, const wchar_t * file_name, unsigned int line_number, unsigned int reserved) Line 204	C++
 	maodbc.dll!_invalid_parameter(const wchar_t * const expression, const wchar_t * const function_name, const wchar_t * const file_name, const unsigned int line_number, const unsigned int reserved) Line 91	C++
 	maodbc.dll!_invalid_parameter_noinfo() Line 97	C++
 	[Inline Frame] maodbc.dll!common_tcscpy_s(char * const) Line 67	C++
 	maodbc.dll!strcpy_s(char * destination, unsigned int size_in_elements, const char * source) Line 19	C++
>	maodbc.dll!_strdup(const char * string) Line 59	C++
 	maodbc.dll!mysql_optionsv(st_mysql * mysql, mysql_option option, ...) Line 2776	C
 	maodbc.dll!MADB_DbcConnectDB(st_ma_odbc_connection * Connection, st_madb_dsn * Dsn) Line 619	C
 	maodbc.dll!MADB_DriverConnect(st_ma_odbc_connection * Dbc, HWND__ * WindowHandle, unsigned char * InConnectionString, unsigned long StringLength1, unsigned char * OutConnectionString, unsigned long BufferLength, short * StringLength2Ptr, unsigned short DriverCompletion) Line 1817	C
 	maodbc.dll!SQLDriverConnectW(void * ConnectionHandle, HWND__ * WindowHandle, wchar_t * InConnectionString, short StringLength1, wchar_t * OutConnectionString, short BufferLength, short * StringLength2Ptr, unsigned short DriverCompletion) Line 1029	C
 	[External Code]	
 	System.Data.ni.dll![Frames below may be incorrect and/or missing, native debugger attempting to walk managed call stack]	Unknown
 	[Managed to Native Transition]	
 	System.Data.dll!System.Data.Odbc.OdbcConnectionHandle.Connect(string connectionString)	Unknown
 	System.Data.dll!System.Data.Odbc.OdbcConnectionHandle.OdbcConnectionHandle(System.Data.Odbc.OdbcConnection connection, System.Data.Odbc.OdbcConnectionString constr, System.Data.Odbc.OdbcEnvironmentHandle environmentHandle)	Unknown
 	System.Data.dll!System.Data.Odbc.OdbcConnectionOpen.OdbcConnectionOpen(System.Data.Odbc.OdbcConnection outerConnection, System.Data.Odbc.OdbcConnectionString connectionOptions)	Unknown
 	System.Data.dll!System.Data.Odbc.OdbcConnectionFactory.CreateConnection(System.Data.Common.DbConnectionOptions options, System.Data.Common.DbConnectionPoolKey poolKey, object poolGroupProviderInfo, System.Data.ProviderBase.DbConnectionPool pool, System.Data.Common.DbConnection owningObject)	Unknown
 	System.Data.dll!System.Data.ProviderBase.DbConnectionFactory.CreateConnection(System.Data.Common.DbConnectionOptions options, System.Data.Common.DbConnectionPoolKey poolKey, object poolGroupProviderInfo, System.Data.ProviderBase.DbConnectionPool pool, System.Data.Common.DbConnection owningConnection, System.Data.Common.DbConnectionOptions userOptions)	Unknown
 	System.Data.dll!System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(System.Data.Common.DbConnection owningConnection, System.Data.ProviderBase.DbConnectionPoolGroup poolGroup, System.Data.Common.DbConnectionOptions userOptions)	Unknown
 	System.Data.dll!System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(System.Data.Common.DbConnection owningConnection, System.Threading.Tasks.TaskCompletionSource<System.Data.ProviderBase.DbConnectionInternal> retry, System.Data.Common.DbConnectionOptions userOptions, System.Data.ProviderBase.DbConnectionInternal oldConnection, out System.Data.ProviderBase.DbConnectionInternal connection)	Unknown
 	System.Data.dll!System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(System.Data.Common.DbConnection outerConnection, System.Data.ProviderBase.DbConnectionFactory connectionFactory, System.Threading.Tasks.TaskCompletionSource<System.Data.ProviderBase.DbConnectionInternal> retry, System.Data.Common.DbConnectionOptions userOptions)	Unknown
 	System.Data.dll!System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(System.Data.Common.DbConnection outerConnection, System.Data.ProviderBase.DbConnectionFactory connectionFactory, System.Threading.Tasks.TaskCompletionSource<System.Data.ProviderBase.DbConnectionInternal> retry, System.Data.Common.DbConnectionOptions userOptions)	Unknown
 	System.Data.dll!System.Data.ProviderBase.DbConnectionInternal.OpenConnection(System.Data.Common.DbConnection outerConnection, System.Data.ProviderBase.DbConnectionFactory connectionFactory)	Unknown
 	System.Data.dll!System.Data.Odbc.OdbcConnection.Open()	Unknown

A bit of poking around (and by all means, dismiss what i say if its not plausible. its my first time debugging something like that) revealed that the strdup function seams to wrongly calculate the size of the plugin path?

i will try to write a small application that produces the same error and will than attach a memory dump.

Comment by Matthias Rauber [ 2020-04-22 ]

To reliably reproduce the error the following requirements has to be met

  • Connection pooling has to be off (x86 and x64)
  • The application in question has to use multiple threads for read and write operations

I created a github (https://github.com/ergofit/odbc-280) repository containing the neccesary solution, sql structure and a memory dump from the crashing process.

Comment by Lawrin Novitsky [ 2020-04-26 ]

I could not reliably reproduce the crash, but few times I did can. But basically I've seen the same picture as in the dump file. Thank you for all
I am pretty much sure I've fixed the issue, but since I can't reliably repeat the crash, I am cannot be 100% sure. but something like 99.5%

I am probably gonna close the ticket anyway. I tried to attach here the file with fixed library, so you could try it in your environment, but for some reason that didn't work. Maybe some new restrictions on attached files have been imposed here.

Comment by Lawrin Novitsky [ 2020-04-26 ]

The fix has been pushed in the commit 2b420d7
The refined description would be: "The connector could crash sometimes, if 2 or more connections were made from different threads at same time." That happened because one function called in the course of connection establishing was reading and writing for the same memory, and its call wasn't guarded by mutexes. The fix changed that completely, since that function is not actually needed to be called each time, and now is called only once during the environment initialization (and is guarded)

Comment by Lawrin Novitsky [ 2020-04-26 ]

I could eventually upload the dll file

Generated at Thu Feb 08 03:27:32 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.