Bug #39464 Error in my_thread_global_end(): 9 threads didn't exit
Submitted: 15 Sep 2008 21:58 Modified: 30 Jul 2009 7:27
Reporter: Roman Zolotarev Email Updates:
Status: Duplicate Impact on me:
None 
Category:Connector / ODBC Severity:S3 (Non-critical)
Version:5.0.67 OS:Linux (ODBC)
Assigned to: CPU Architecture:Any

[15 Sep 2008 21:58] Roman Zolotarev
Description:
I am meeting the problem in my server with linux fedora 8 and Lotus Domino.

OS: Linux Fedora 8
Lotus Domino server 7.0.3

I am sorry, but I am not programmer, just administrator. I try to describe problem.

Server - Linux Fedora 8
mysql server - 5.0.67
compiled from source:
./configure --prefix=/usr --with-extra-charsets=all --enable-thread-safe-client --with-pthread --with-unix-socket-path=/var/lib/mysql/mysql.sock --datadir=/var/lib/mysql

ODBC connector:
mysql-connector-odbc-5.1.5r1144 also compiled from source.

I have error messages in domino log when I get access to mysql through LSX connector (odbc mode):
Error in my_thread_global_end(): 9 threads didn't exit
Error in my_thread_global_end(): 9 threads didn't exit

When error appear, server get delay in answer, but all requests to mysql, after delay, works ok.

I changed piece of code in mysql-connector-odbcxxxxx file dll.c:

void myodbc_end()
{
  if (!--myodbc_inited)
  {
    my_free(decimal_point,MYF(0));
    my_free(default_locale,MYF(0));
    my_free(thousands_sep,MYF(0));

    /* my_thread_end_wait_time was added in 5.1.14 and 5.0.32 */
#if !defined(NONTHREADSAFE) && \ 
    (MYSQL_VERSION_ID >= 50114 || \ 
     (MYSQL_VERSION_ID >= 50032 && MYSQL_VERSION_ID < 50100)) 
    /* 
       This eliminates the delay when my_end() is called and other threads 
       have been initialized but not ended. 
    */
    my_thread_end_wait_time= 0;
#endif 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!    my_thread_end_wait_time= 0;   !!! I insert this line.

#ifdef MY_DONT_FREE_DBUG 
    /* 
       Function my_end() was changed to deallocate DBUG memory by default, 
       a flag MY_DONT_FREE_DBUG was added to disable this new behaviour 
    */
    my_end(MY_DONT_FREE_DBUG);
#else 
    my_end(0);
#endif 
  }
}

After that, delay is disappear, and all works fine, but messages is still appears in log. I don't know, is it possible to use it in production mode servers.
Is it possible memory leak or another troubles ?
I tryed to place comment in http://bugs.mysql.com/bug.php?id=37226

How to repeat:

OS: Linux Fedora 8
Lotus Domino server 7.0.3
mysql server - 5.0.67 (5.0.46 the same problem)
mysql-connector-odbc-5.1.5r1144 (5.1.4 too)

/etc/odbcinst.ini
[ODBC]
[MySQL]
Description     = ODBC for MySQL
Driver          = /usr/lib/libmyodbc5.so
Setup           = /usr/lib/libmyodbc3S.so
SOCKET          = /var/lib/mysql/mysql.sock
FileUsage       = 1

/etc/odbc.ini
[CMStemplateodbc]
DSN             = CMStemplateodbc
DRIVER          = /usr/lib/libmyodbc5.so
SERVER          = localhost
DATABASE        = CMStemplate
USER            = user
PASSWORD        = password
PORT            = 3306
OPTION          =
SOCKET          = /var/lib/mysql/mysql.sock
charset         = utf8

Lotus Script agent:
	
Dim src As New LCConnection ("odbc2")
Dim fldLst As New LCFieldList

src.server = CMStemplateodbc
src.userid = user
src.password = password
	
On Error Goto Trap_error_connection_to_base
src.Connect
	
SQLSTR="SELECT * FROM `Table`"
count=src. Execute (SQLSTR,  fldLst)

Suggested fix:
http://bugs.mysql.com/bug.php?id=37226 but in windows enviroment.
[16 Sep 2008 10:12] Tonci Grgin
Roman, as I said before:

Bug #32366: "ODBC Connection to MySQL using VBScript (WScript.exe)"
Bug #32986: "MyODBC recordset returns bad data and causes error in my_thread_global_end"
and master of all
Bug #25621: "Error in my_thread_global_end(): 1 threads didn't exit"

I think there might be two problems here:
  1) "threads don't exit" in server. This should be patched in 5.0.70 afaik.
  2) Wait for c/ODBC release to be linked against 5.0.70 libraries.

So, this is a duplicate of abovementioned bugs and we are aware of the problem. I will not close the bug for now but rather discuss it during upcoming DevCon.
[16 Oct 2008 23:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[13 May 2009 14:57] Cristian Suciu
Hi,

I attached a simple application that prints the "Error in my_thread_global_end(): X threads didn't exit" message.

The environmental handler is global and is created on main thread. The first connection is created on the main thread too and is closed after all working threads are finished. Creating the environmental handler and/or making a new connection will call my_thread_init() where THR_thread_count counter is incremented. The counter is decremented only when the SQLDisconnect() is called from main thread. When working threads are disconnecting there is no call to my_thread_end(), so the counter remains the same. Finally, when my_thread_global_end() will be called the counter value will be the same with the number of working threads created and the message is printed.

Why SQLDisconnect() from working threads do not decrement the THR_thread_count counter?

To compile:
$ gcc -g -o gmodel_odbc gmodel_odbc.c -I<sql.h directory> -L<libodbc.so directory> -lodbc -lpthread

To test:
$ ./gmodel_odbc  -d MySQL_rd_Essbase7 -u rnddb15 -p rnddb15 -n 2
Connected. Press any key to start threads! : 3086273024l
WorkingThread: started : 3086269328l
WorkingThread: started : 3073682320l
WorkingThread: stopped : 3086269328l
WorkingThread: stopped : 3073682320l
Threads finished. Press any key to disconnect! : 3086273024l
Error in my_thread_global_end(): 2 threads didn't exit

Where: -d is the DSN, -u is the user name, -p is the password and -n is the number of working threads.

Regards,
Cristian
[13 May 2009 15:04] Cristian Suciu
I forgot to mention that all test where done on RedHat52, 32bit, kernel  2.6.18-92.el5, MySQL Connector/ODBC 5.1.5 and 3.51.27 and unixODBC 2.2.14 as manager.

Cristian
[30 Jul 2009 7:27] Tonci Grgin
Sorry Roman, I missed this report...

This is actually a duplicate of several bugs, primarily Bug#32366:
The message you are seeing does not originate from the server, it comes from the client library used by the driver. There was an older bug where the server itself would print this message (to wherever it is that server output is set to go, not to client applications), but this bug was fixed in recent server versions (Bug#25261).
[26 Oct 2010 6:35] Bogdan Degtyariov
The problem has not been solved for Unix/Linux systems.
To be continued in bug #57727