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: | |
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
[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.