Bug #32857 Application linked dynamically to MyODBC crashes
Submitted: 29 Nov 2007 20:43 Modified: 31 Dec 2007 13:50
Reporter: Bogdan Degtyariov Email Updates:
Status: Closed Impact on me:
None 
Category:Connector / ODBC Severity:S3 (Non-critical)
Version:3.51.22 OS:Linux
Assigned to: Bogdan Degtyariov CPU Architecture:Any
Tags: linking, thread

[29 Nov 2007 20:43] Bogdan Degtyariov
Description:
A multithreaded (even STL) application that loads MyODBC directly (MyODBC is linked dynamically) without UnixODBC crashes when calling SQLAllocStmt(). This bug never occurs with UnixODBC because the driver manager creates additional synchronization points. 

How to repeat:
The test case shall be ready soon.
[29 Nov 2007 20:55] Bogdan Degtyariov
Sorry, the application is single-threaded, so it is not a synchronization problem.
[13 Dec 2007 14:02] Bogdan Degtyariov
This IS the problem with threads synchronization. Occurs when MyODBC is loaded/linked directly to application or through unixODBC providing the Threading parameter in odbcinst.ini is lower than 3 (3 is the default value if the parameter is omitted. That is why ODBC programs did not crash at that point if linked against unixODBC and the parameter not set explicitly).

Unfortunately, there is no test case that could reproduce the bug on 100%. Everything we have is a C program that can reproduce the crash if running in infinite loop for some long time (up to 2-3 minutes).

Crashes have been fixed (see the patch below) by adding locks in proper places.
[13 Dec 2007 14:05] Bogdan Degtyariov
Patch without test case. It was not included because the problem occured randomly providing the loop is running infinitely ~3min

Attachment: patch32857.diff (application/octet-stream, text), 1.29 KiB.

[21 Dec 2007 17:28] Lawrenty Novitsky
Bogdan, approved
[31 Dec 2007 13:50] MC Brown
A note has been added to the 3.51.23 changelog: 

When using unixODBC or directly linked applications where the thread level is set to less than 3 (within odbcinst.ini), a thread synchronization issue would lead to an application crash. This was because SQLAllocStmt() and SQLFreeStmt() did not synchronize access to the list of statements associated with a connection.