Mailing List
Home
Forum Home
MySQL General - General MySQL discussion
MySQL++ - Programming with the C++ API to MySQL
MaxDB - Everything about MaxDB, formerly known as SAP DB
ODBC - ODBC with the MySQL Connector/ODBC driver
MySQL on Win32 - Runing MySQL on Windows 9x/Me/NT/2000/XP
Java Help - Mostly related to the MySQL Connector/J driver
Perl - Perl support for MySQL with DBI and DBD::mysql
GUI - MySQL GUI Tools
Announcement
Subjects
• mysql openssl Question
• mysql:it 's a db not a dbms how it 's possible?!
• Does the binary log enabling affect the MySQL performances?
• Strange behavior, Table Level Permission
• FULLTEXT query format question
• Preventing Duplicate Entries
• Comparing and writing out BLOBS
• Executing MySQL Commands From Within C Program
• Can 't access mysql after kernel upgrade
• Mysql 4 0 Oracle Stored Procedure Trigger Conversion
• Downgrade Mysql from 4 to 3 23
• MySQL Cluster Software
• mysql test 4 1 fails with the gis test
• ERROR 2002: Can 't connect to local MySQL server through socket
• Getting Identity after INSERT
• Update one field with more fields from another table
• ERROR 1045: Access denied for user: 'root@localhost ' (Using
password: NO)
• mysql have same function mthod as Oracle decode()
 
Crash while using a multithreaded application with OTL/ODBC to access a mySQL db

Crash while using a multithreaded application with OTL/ODBC to access a mySQL db

2006-07-11       - By Khera, Aniket

 Back
Hello,



We are using OTL 4.0 to access a mysql database. From the documentation,
it seems that the otl library is not threadsafe. In our application, we
have two threads accessing the otl_connect object and we were seeing
crashes while running load test. Following is the backtrace from gdb:



(gdb) bt

#0  0x008f5353 in list_add () from /usr/lib/libmyodbc3-3.51.11.so

#1  0x008e107a in my_SQLAllocStmt () from /usr/lib/libmyodbc3-3.51.11.so

#2  0x008e14cf in SQLAllocHandle () from /usr/lib/libmyodbc3-3.51.11.so

#3  0x00832143 in otl_cur::open (this=0xb7239808, connect=@(protected)) at
otlv4.h:9161

#4  0x008319b1 in otl_tmpl_cursor<otl_exc, otl_conn, otl_cur,
otl_var>::open (this=0xb72397f8, connect=@(protected), var=0x0) at
otlv4.h:3536

#5  0x0082f927 in otl_tmpl_cursor (this=0xb72397f8, connect=@(protected))
at otlv4.h:3494

#6  0x0082a758 in otl_tmpl_select_cursor (this=0xb72397f8,
pdb=@(protected), arr_size=50, sqlstm_label=0x0) at otlv4.h:4559

#7  0x00828038 in otl_tmpl_select_stream (this=0xb72397f8,
aoverride=0xb7237a14, arr_size=50,

   sqlstm=0xb72582c8 "SELECT PublicUserIdentityIndex FROM
PublicUserIdentity WHERE PublicUserId=\"2212436166\";", pdb=@(protected),
implicit_select=0,

   sqlstm_label=0x0) at otlv4.h:4750

#8  0x00825e4a in otl_stream::open (this=0x4573900, arr_size=50,

   sqlstm=0xb72582c8 "SELECT PublicUserIdentityIndex FROM
PublicUserIdentity WHERE PublicUserId=\"2212436166\";", db=@(protected),
implicit_select=0,

   sqlstm_label=0x0) at otlv4.h:11147

#9  0x00249671 in SmaGetPublicIndex::prepare (this=0x4574700,
publicId=0xb7256444 "2212436166", publicIdx=0x457473c) at
SmaGetPublicIndex.cpp:89 #10 0x008015d8 in
DaSubsMgrTask::handleDaapiGetAuthDataRpy (this=0x82ed738,
daapi=0xb72563c8, context=0x83c4830) at DaSubsMgrTask.cpp:461



We changed the code to instantiate two otl_connect objects (with the
same connect params) and now have each thread accessing the database
through its dedicated otl_connect object. However, we are still seeing
the same core. From the backtrace, we noticed that the connect pointer
(highlighted in red above) has moved by a byte?



Any pointers on the above will be very helpful. I had queried the author
of OTL (Sergei Kuchin) and he seems to believe that this may be an issue
with ODBC.



Thanks,

Aniket