[unixODBC-support] Multi-thread testing

Brian Reynolds Brian.Reynolds at risaris.com
Fri Aug 19 16:05:15 BST 2011

Resending in plain-text ...

Hi Folks,

I'm doing some tests to simulate concurrent user load, and hitting some 
problems. I'm seeing very inconsistent behaviour, and I need to help to 
figure it out.

Firstly, my setup -:
+ OS : openSuSE 11.4
+ Compiler : gcc version 4.5.1 20101208 [gcc-4_5-branch revision 167585] 
(SUSE Linux)
+ unixODBC : 2.3.0 ( ./configure --prefix=/home/brian/cvsdev/unixODBC/ 
--disable-gui )
+ MySQL Ver 14.14 Distrib 5.1.53, for suse-linux-gnu (i686) using 
readline 6.1
+ MyODBC 5.1.8 ( ./configure 
--prefix=/home/brian/cvsdev/MyODBC_518/ --disable-gui )

and I've simplified my problem down to one C program. The program does a 
SQLAllocHandle and SQLSetEnvAttr in the main to allocate a environment 
handle - the handle is declared globally. It then creates 64 threads 
(using pthread_create) which will, SQLAllocHandle (for DBC), SQLConnect, 
SQLAllocHandle (for STMT) , SQLFreeHandle (for STMT), SQLDisconnect, 
SQLFreeHandle for the DBC, and then pthread_exit. Nothing too complex.

So what I'm seeing is mixture of the following:

1. Messages like "Error in my_thread_global_end(): 62 threads didn't 
exit". I can reduce the number of threads down significantly (to 8 
threads) and I still get this message, with the number of threads not 
exiting appropriately reduced.

2. The error "[unixODBC][Driver Manager]Driver does not support the 
requested version" when one of the threads is trying to do SQLConnect. 
This is most prevalent when I run my test via gdb.

3. Memory corruptions, e.g : *** glibc detected *** 
/home/brian/cvsdev/xmiddle/src/test/test02: corrupted double-linked 
list: 0xb2f11058 ***, when doing the SQLDisconnect:

(gdb) bt
#0  0xffffe424 in __kernel_vsyscall ()
#1  0xb7ce38df in raise () from /lib/libc.so.6
#2  0xb7ce5220 in abort () from /lib/libc.so.6
#3  0xb7d1fe07 in __libc_message () from /lib/libc.so.6
#4  0xb7d25e2b in malloc_printerr () from /lib/libc.so.6
#5  0xb7d2627c in malloc_consolidate () from /lib/libc.so.6
#6  0xb7d26b47 in _int_free () from /lib/libc.so.6
#7  0xb7d2aa6d in free () from /lib/libc.so.6
#8  0xb7cd04ea in __gconv_close () from /lib/libc.so.6
#9  0xb7ccfa1a in iconv_close () from /lib/libc.so.6
#10 0xb7fba525 in unicode_shutdown (connection=0x804b7f8) at __info.c:615
#11 0xb7f828a6 in __disconnect_part_four (connection=0x804b7f8) at 
#12 0xb7f82960 in __disconnect_part_three (connection=0x804b7f8) at 
#13 0xb7f870df in SQLDisconnect (connection_handle=0x804b7f8) at 
#14 0x08048c4f in runRequest (arg=0x0) at nativeODBCTest.cpp:118
#15 0xb7ca2b05 in start_thread () from /lib/libpthread.so.0
#16 0xb7d8bd5e in clone () from /lib/libc.so.6

4. The error message : "[unixODBC][Driver Manager]Can't open lib 
'/home/brian/cvsdev/MyODBC_518/lib/libmyodbc5.so' : file not found"  - 
which is very strange, as this file has been found by all other threads, 
so it isn't a configuration issue.

My odbcinst.ini contains:

Driver = /home/brian/cvsdev/MyODBC_518/lib/libmyodbc5.so
UsageCount        = 1
Threading = 3
DontDLClose     = 1

I've tried various values on the Threading directive, each without much 
difference. My understanding that since my libmyodbc5.so is using the 
libsqlclient_r.so library, everything should be thread-safe?

Finally, a quick run with valgrind shows:

==31967== HEAP SUMMARY:
==31967==     in use at exit: 20,734 bytes in 584 blocks
==31967==   total heap usage: 47,446 allocs, 46,862 frees, 19,141,158 
bytes allocated
==31967== Thread 1:
==31967== 116 bytes in 1 blocks are definitely lost in loss record 52 of 63
==31967==    at 0x40277F1: calloc (in 
==31967==    by 0x1E09B36B: my_thread_init (in 
==31967==    by 0x1E09B5D4: my_thread_global_init (in 
==31967==    by 0x1E095B6B: my_init (in /usr/lib/libmysqlclient_r.so.16.0.0)
==31967==    by 0x7FA5936: myodbc_init (dll.c:65)
==31967==    by 0x403EBBB: SQLConnect (SQLConnect.c:3886)
==31967==    by 0x8048B23: runRequest(void*) (nativeODBCTest.cpp:88)
==31967==    by 0x435BB04: start_thread (in /lib/libpthread-2.11.3.so)
==31967==    by 0x42BCD5D: clone (in /lib/libc-2.11.3.so)
==31967== 7,076 bytes in 61 blocks are definitely lost in loss record 63 
of 63
==31967==    at 0x40277F1: calloc (in 
==31967==    by 0x1E09B36B: my_thread_init (in 
==31967==    by 0x1E08FF3C: mysql_server_init (in 
==31967==    by 0x1E0C0839: mysql_init (in 
==31967==    by 0x7FA07B7: myodbc_do_connect (connect.c:164)
==31967==    by 0x7FA1089: MySQLConnect (connect.c:419)
==31967==    by 0x7F96D74: SQLConnect (ansi.c:271)
==31967==    by 0x403EC1B: SQLConnect (SQLConnect.c:3923)
==31967==    by 0x8048B23: runRequest(void*) (nativeODBCTest.cpp:88)
==31967==    by 0x435BB04: start_thread (in /lib/libpthread-2.11.3.so)
==31967==    by 0x42BCD5D: clone (in /lib/libc-2.11.3.so)
==31967== LEAK SUMMARY:
==31967==    definitely lost: 7,192 bytes in 62 blocks
==31967==    indirectly lost: 0 bytes in 0 blocks
==31967==      possibly lost: 0 bytes in 0 blocks
==31967==    still reachable: 13,542 bytes in 522 blocks
==31967==         suppressed: 0 bytes in 0 blocks
==31967== Reachable blocks (those to which a pointer was found) are not 

I would assume, all these issues are related to each other - and most 
likely it is some kind of thread-safety issue. I'd appreciate any help...



More information about the unixODBC-support mailing list