MySQL Bugs: #25621: Error in my_thread_global

Bug #25621	Error in my_thread_global_end(): 1 threads didn't exit
Submitted:	15 Jan 2007 9:38	Modified:	6 Jul 2007 21:51
Reporter:	Shane Bester (Platinum Quality Contributor)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: General	Severity:	S1 (Critical)
Version:	5.0.34,5.0.36BK	OS:	Windows (windows)
Assigned to:		CPU Architecture:	Any
Tags:	bfsm_2007_01_18

Description:
when issuing a normal "mysqladmin shutdown", the following error
has recently been seen in the error logs:

Error in my_thread_global_end(): 1 threads didn't exit

How to repeat:
start a mysqld-nt or mysqld-debug server.
from another window run "mysqladmin shutdown".

Suggested fix:
find out which thread called mysql_thread_init but forgot to call mysql_thread_end ?

D:\builds\mysql-5.0.34-win-src\mysql-5.0.34\client_debug>mysqld-debug --console --skip-grant-tables --port=3307
070115 12:18:00  InnoDB: Started; log sequence number 0 43655
070115 12:18:06 [Note] mysqld-debug: ready for connections.
Version: '5.0.34-debug'  socket: ''  port: 3307  yes
070115 12:18:30 [Note] mysqld-debug: Normal shutdown

070115 12:18:32  InnoDB: Starting shutdown...
070115 12:18:35  InnoDB: Shutdown completed; log sequence number 0 43655
070115 12:18:35 [Note] mysqld-debug: Shutdown complete

Maximum memory usage: 8559983 bytes (8360k)
Error in my_thread_global_end(): 1 threads didn't exit

D:\builds\mysql-5.0.34-win-src\mysql-5.0.34\client_debug>

How do you resolve this?  I am having this same problem but have been unable to resolve this.  Thanks

-Andrew

I'm having the same problem with 5.0.36 under debian.
I have no idea how to resolve this.

I get the same error message when trying to upgrade from MySQL 5.0.27 to 5.0.37 using RPM packages on a CentOS 3 platform:

===================================
# rpm -Uvh MySQL-server-community-5.0.37-0.rhel3.i386.rpm
warning: MySQL-server-community-5.0.37-0.rhel3.i386.rpm: V3 DSA signature: NOKEY, key ID 5072e1f5
Preparing...                ########################################### [100%]
Giving mysqld a couple of seconds to exit nicely
   1:MySQL-server-community ########################################### [100%]
Error in my_thread_global_end(): 1 threads didn't exit
Error in my_thread_global_end(): 1 threads didn't exit
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h host.mymy.com.au password 'new-password'
See the manual for more instructions.

NOTE:  If you are upgrading from a MySQL <= 3.22.10 you should run
the /usr/bin/mysql_fix_privilege_tables. Otherwise you will not be
able to use the new GRANT command!

Please report any problems with the /usr/bin/mysqlbug script!

The latest information about MySQL is available on the web at
http://www.mysql.com
Support MySQL by buying support/licenses at http://shop.mysql.com
Starting MySQL....................................................................................../var/tmp/rpm-tmp.3924: line 78: 17386 Terminated              /etc/init.d/mysql start
===================================

My system:

===================================
# uname -a
Linux mysql.localdomain.com 2.4.20-021stab028.19.777-enterprise #1 SMP Wed Oct 19 13:05:01 MSD 2005 i686 i686 i386 GNU/Linux
===================================

I tried to reproduce this problem using current bk sources on Windows XP and Ubuntu Edgy Eft and was only able to produce the error on Windows.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/25160

ChangeSet@1.2437, 2007-04-23 14:28:33-04:00, iggy@recycle.(none) +1 -0
  Bug#25621 Error in my_thread_global_end(): 1 threads didn't exit
  - On Windows, connection handlers while exiting properly did not 
  decrement the server's thread count.

Pushed into 5.1.18-beta

Pushed into 5.0.42

I'm sorry to ask this, but I cannot find the answer. How do I install this patch? I am running MySQL 5.0.37 on Windows 2003 Server and have the same problem.
Thanks,
Patrick

This error is not only in mysql shutdown, it is also at the bottom of every single PHP 5 page on the application I am installing.  It writes it out to the bottom of very page after 5 seconds, which really slows down my application.

Is this going to be released in compiled form anytime soon?  I don't want to compile as I'm on Windows and it's a big pain.  ETA on release for Community Server?

This error is also happening on the bottom of every page in MySQL 4.1.22 as well at 5.0.37

I have been patiently waiting for this to be fixed because I am trying to run both phpBB3 and Wordpress using MySQL. I tried moving phpBB3 to MSSQL as a temporary fix but that didn't work because PHP still references MySQL and can't be disabled because Wordpress only works on MySQL.

Wordpress runs slowly with this bug and phpBB3 has massive problems on the IE platform because of this bug. I've actually given up on phpBB3 until this is fixed.

Results of my recent searches in trying to find a workaround have revealed a growing number of programs that use PHP and MySQL are starting to fall over on Win systems. You MUST disable MySQL on PHP but obviously that makes life impossible if you need MySQL in one program environment and not in another :-(

I'm glad and sad to see I'm not the only one who is having this issue.  This is definitely a major bug and I'm wondering when a fix for this major issue is going to be released.

This kind of error should never occur in a production release! Period. Sorry guys, but developing multi-threaded applications without proper tools (like Intel's Thread Checker) which promptly detect such errors is ridiculous. And tells a lot about quality check here.

I tried the beta and I'm still getting this error. It's causing MAJOR performance issues on our sites.  Can some one shed some light on how to resolve this?

Strictly speaking, this is not MySQL bug. This is a client bug - a client application (PHP, probably) linked with libmysqlclient calls my_thread_init() but does not call my_thread_end() as appropriate (doesn't call at all or calls too late). MySQL client library detects this and issues a warning.

On the other hand, we can just remove the check and let buggy applications to fail some other way. Not calling my_thread_end() is a guaranteed memory leak. Calling it too late could easily crash the application.

Mr. Sergei Golubchik,
I can asure you that that is not the problem.

For example, when I start database, do nothing for couple of seconds and shutdown it, the error appears. There is no client program that is working with database and it still shows error.

So, its a MySQL BUG!

Rade, this is different. There're two different sympthoms here.

One is a warning when MySQL *server* is shut down. This was fixed, and as you can see in earlier comments will be in 5.0.42 release.

The other is the warning on php pages, that is on the *client* side. My comments refers to this sympthom - a warning on PHP pages is caused by incorrect usage of MySQL client C API, I think.

Noted in 5.0.42, 5.1.18 changelogs.

On Windows, connection handlers did not properly decrement the
server's thread count when exiting.

Leaving report Open pending action on the client issue being
discussed in the recent comments.

Here's what derick@php.net at PHP had to say:

"We don't call my_thread_init, or anything starting with my_thread:"

I have the same issue even when the script doesn't call any MySQL, but this error only happens when using fast-cgi If I run php 5.2.2 ISAPI the problem goes away.

If I remove extension=php_mysql.dll from php.ini the issue also goes away when using fast-cgi

Glen, this is easy - my_thread_init() is called indirectly from mysql_init().
But I cannot find where my_thread_global_end() is called from - and it is apparently called from somewhere as it is a function that prints the warning.

Sergei, this is easy: Have a look at the original (15th Jan 2007) Suggested fix above.

The output being displayed on the web pages, according to the phpBB3 people, is generated by PHP's call to MySql to fetch the required data. The error message is just being appended to the data returned by MySql to PHP.

It seems to me that the problem lies in the PHP dll "php_mysql.dll" as it is opening the threads but not telling MySql to close them. This may also account for the error being generated whether you use MySql database or not - just calling php_mysql.dll is bad enough.

As you have already pointed out, should MySQL be changed to not produce the error and (presumably) just simply drop the threads and don't tell anyone OR should who-ever wrote php_mysql.dll be requested to fix their error in not requesting all threads to be closed?

Frankly, I'm no expert and I have no way to easily determine where the problem lies but I bet someone should be able to fix this very quickly - that is if it hasn't been already.

ok, thanks. "dll" was the key. There's some magic happening when libmysqlclient.dll (or whatever the name) is loaded and unloaded. my_end() (which calls my_thread_end() and my_thread_global_end() is called from there).

There's no magic in the linux libmysqlclient.so, as far as I can see. Which is not very helpful for portable applications.

So, we need to either
1. say that a client must init/deinit the library
or
2. it happens automatically

in 1. the warning is a php bug (in php_mysql.c), but we probably need to remove auto-init/deinit magic from dll.
in 2. auto-init/deinit must be fixed to work on linux too. and it should not cause warnings, the warning is our bug.

Sergei, could you please tell George Richter and Andrei Hristov how to deinitilize the library correctly?
Believe it or not, but they are the maintainers of MySQL support in PHP, so if there is _indeed_ something wrong in PHP (I'm still not convinced, since it worked for ages and only broke recently), I guess they would really want to know how to fix it correctly.
Thanks in advance.

Btw, I can't find any docs on my_end(). At least not using search on the site. 
I suppose this is something new and it doesn't fix the problem _for real_ since we can't require everybody to use the latest and the greatest version of MySQL.

It's documented here:
http://dev.mysql.com/doc/refman/5.0/en/mysql-library-end.html
mysql_library_end is just a different name for mysql_server_end (simple #define), and mysql_server_end existed since 2001-08-10

I started seeing this bug after upgrading from PHP 5.1.x to 5.2.2. Interestingly, copying the libmysql.dll from the 5.1.x version in to the 5.2.2 release appears to have resolved the issue at list until the underlying problem is addressed.

I have upgraded to PHP 5.2.2.
I cfm that using libmysql.dll from 5.2.1, instead of 5.2.2 solved the pbm.

This error occurs since PHP upgraded to libmysql 5.0.37.

We're getting these same issues. 

Just installed PHPBB3 with MySQL 5.0.41 and PHP 5.2.2

Was getting the message Error in my_thread_global_end(): 1 threads didn't exit like so many others have, and tried replacing the PHP libmysql.dll from the 5.2.1 package.  Now I get Error in my_thread_global_end(): 2 threads didn't exit at the top.

Anyone gotten this or have a solution?

I think that you will find the error that was generated when you configured phpBB3 was written to the end of the config.php file. Delete everything after "?>".

Wow, that's cool!

Code of the page:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/dtd/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru">
<head><title>Devgru &mdash; MyWeBlog</title></head>
<body><?php ?></body>
</html>

Result is
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/dtd/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru">
<head><title>Devgru &mdash; MyWeBlog</title></head>
<body></body>
</html>Error in my_thread_global_end(): 1 threads didn't exit

Same behaviour when aborting mysql client via Ctrl-C:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.0.41-community-nt MySQL Community Edition (GPL)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> Aborted
Error in my_thread_global_end(): 1 threads didn't exit

For what it's worth I'm having problems on RHEL-4 U2

rpm -ivh MySQL-server-5.0.41-0.x86_64.rpm 
Preparing...                ########################################### [100%]
   1:MySQL-server           ########################################### [100%]
Error in my_thread_global_end(): 1 threads didn't exit

Additionally mysql will not start with safe_mysqld, it will only operate under mysqlmanager

Also the install portion of the RPM gets stuck producing 

root      5874  0.0  0.0 52740 1104 pts/0    S    18:00   0:00 /bin/sh /usr/bin/mysql_install_db --rpm --user=mysql
mysql     5877  0.0  0.0 22128 3412 pts/0    S    18:00   0:00 /usr/sbin/mysqld --bootstrap --basedir=/ --datadir=/var/lib/mysql --skip-innodb --skip-bdb --skip-ndbcluster --user=mysql --max_allowed_packet=8M --net_buffer_length=16K
root      5878  0.0  0.0 22128 3412 pts/0    S    18:00   0:00 /usr/sbin/mysqld --bootstrap --basedir=/ --datadir=/var/lib/mysql --skip-innodb --skip-bdb --skip-ndbcluster --user=mysql --max_allowed_packet=8M --net_buffer_length=16K
root      5880  0.0  0.0 22128 3412 pts/0    S    18:00   0:00 /usr/sbin/mysqld --bootstrap --basedir=/ --datadir=/var/lib/mysql --skip-innodb --skip-bdb --skip-ndbcluster --user=mysql --max_allowed_packet=8M --net_buffer_length=16K

070530 18:15:41  InnoDB: Operating system error number 11 in a file operation.
InnoDB: Error number 11 means 'Resource temporarily unavailable'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html
InnoDB: Could not open or create data files.
InnoDB: If you tried to add new data files, and it failed here,
InnoDB: you should now edit innodb_data_file_path in my.cnf back
InnoDB: to what it was, and remove the new ibdata files InnoDB created
InnoDB: in this failed attempt. InnoDB only wrote those files full of
InnoDB: zeros, but did not yet use them in any way. But be careful: do not
InnoDB: remove old data files which contain your precious data!

Doing an strace when running mysqld from the command line I get 

open("/var/lib/mysql/ibdata1", O_RDWR)  = 8
fcntl(8, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
open("/var/lib/mysql/ib_logfile0", O_RDWR) = 13
fcntl(13, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
open("/var/lib/mysql/ib_logfile1", O_RDWR) = 14
fcntl(14, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
mmap(NULL, 2101248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2d4e9c4000
mmap(NULL, 1359986688, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2d4ebc5000
pread(13, "\0\0\0\0\0\7GX\0\0\0\25d\352\r@$\357M@\1\0\0\0\377\377"..., 512, 512) = 512
pread(13, "\0\0\0\0\0\7GY\0\0\0\25d\352\r@$\357M@\1\0\0\0\377\377"..., 512, 1536) = 512
pread(13, "\0\0\0\0\0\7GY\0\0\0\25d\352\r@$\357M@\1\0\0\0\377\377"..., 512, 1536) = 512
pread(13, "\0\0\0\0\0\0\0\25?\372\320\0\0\0\0\0    \0\0\0\0\0\0\0"..., 2048, 0) = 2048
pread(8, "\341W\7n\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\25d\352\r@\0\0\0"..., 16384, 81920) = 16384
mmap(NULL, 2117632, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2d9fcc1000
pread(8, "\341W\7n\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\25d\352\r@\0\0\0"..., 1048576, 1048576) = 1048576
pread(8, "\r@\215W\0\0\3q\0\0\3m\377\377\377\377\0\0\0\25d\314\216"..., 1048576, 2097152) = 1048576
pread(14, "\212\262u\7\1@\0/\0\7GSnfo\1\0\0\0\0\0\0\0\0vern.fs@"..., 65536, 82791424) = 65536
pread(14, "\212\262u\7\1@\0/\0\7GSnfo\1\0\0\0\0\0\0\0\0vern.fs@"..., 512, 82791424) = 512
time(NULL)                              = 1179341853
kill(28977, SIGRTMIN)                   = -1 EPERM (Operation not permitted)
sched_yield()                           = 0
time(NULL)                              = 1179341853
rt_sigprocmask(SIG_SETMASK, NULL, [HUP INT QUIT PIPE TERM TSTP RTMIN], 8) = 0
rt_sigsuspend([HUP INT QUIT PIPE TERM TSTP]

so, for some reason since mysql-5.0.34 there has been a problem with mysql and the start process. I believe it's tied to mysqlmanager changes.

Still a problem on MySQL 5.0.41 under Windows Server 2003 / IIS 6 / PHP 5.2.3. Can be fixed by copying libmysql.dll from PHP 5.2.1.

Seems as if neither side wants to take ownership of the bug. Nothing is happening over at the PHP bug (http://bugs.php.net/bug.php?id=41350), even though people here are saying it's their problem.

Please can someone fix this bug before the next release of PHP?

In PHP 5.2.3 this is still not fixed!

I can confirm this bug on Windows Server 2003 using PHP 5.2.3 or 5.2.2 and MySQL 5.0.41. By using libmysql.dll from PHP 5.2.1 the error is gone.

The error became a visible with PHP 5.2.2, without upgrading MySQL. No matter who is to blame for it, it must be fixed in PHP, at least for MySQL 5.0.

Stop discussing the source of the problem. Fix it, using the way PHP 5.2.1 accessed MySQL. This is serious.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/29197

ChangeSet@1.2517, 2007-06-20 19:22:27+03:00, monty@mysql.com +5 -0
  Allow multiple calls to mysql_server_end()
  (Part of fix for Bug#25621 Error in my_thread_global_end(): 1 threads didn't exit)
  Give correct error message if InnoDB table is not found
  (This allows us to drop a an innodb table that is not in the InnoDB registery)

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/29232

ChangeSet@1.2488, 2007-06-21 08:58:39+02:00, df@pippilotta.erinye.com +1 -0
  Steal part of fix for bug#25621 from monty for 5.0.44.

Patch also in 5.1.20. Extract from IRC cchar on 2007-06-25:
[08:06] <joerg> trudy: I discussed it with Daniel and Georg, and then merged the 5.0.44 patch to 5.1 (buiuld team tree), and pull that into the 5.1.20 clone.
[08:07] <joerg> trudy: So it is not yet in 5.1 main tree, but will be in 5.1.20

Added this to the 5.1.20 change history:

On Windows, an application that called mysql_thread_init but forgot to call mysql_thread_end would get this error: Error in my_thread_global_end() (Bug #25621)

Setting the bug to 'Patch pending' because the patch will be backported to 5.0.

The patch for the PHP extensions will be committed by Scott MacVicar, probably today.

Patch is already in the PHP CVS, will be part of the next PHP5 release:

http://marc.info/?l=php-cvs&m=118278731523645&w=2

Patch queued (already exists in release clones for 5.0.44 and 5.1.20, and queued in -marvel team tree).

Pushed into 5.0.46

Pushed into 5.1.21-beta

The 5.0.x changelog entry was in the 5.0.42 section.
I moved it to 5.0.44.

The error message "Error in my_thread_global_end(): 1 threads didn't" is outputed also when using ODBC 3.51.16 on Windows. Version 3.51.14 is OK.

Pushed into 5.1.21-beta

Pushed into 5.0.48

I'm running MySql v5.0.45.
The bug appears in all MyOdbc > v3.51.15. So, something broke when going from 3.51.15 to 3.51.16.

Why is this bug closed? It states that this will be fixed in v5.0.48, but isn't it a bug of MyOdbc v3.51.16 and up?

Sander, shouldn't be. There is no firm logic to support your statement. What happened, probably, is that some part of code in MyODBC was handling this problem but it was removed as the proper fix should be in server.

Although original behavior reported by Shane was visible in 5.0.48PB I can not repeat it with 5.0.50-pb1046 on WinXP Pro SP2.

On Windows Vista 64 with Connector 3.51 both 32 and 64 bit simply opening an closing a connection will hang the exit of the application for several seconds then produce "Error in my_thread_global_end()". 

I am not running MySQL at all - just the connector.

Repeat by:

OdbcConnection connection = new OdbcConnection("DRIVER={MySQL ODBC 3.51 Driver}; ....
connection.Open();
connection.Close();

I have managed to resolve this problem quite easy. I wanted to test a simple mysql  program on Windows with MySQL 5.0 (5.0.27 client) and the C API from Visual C++ 8.0. 

So I first linked to mysqlclient.lib. That worked fine. I guess that's the static version. 

Then I thought about trying to link to libmysql.lib. This is only 35KB and of course it is just an interface to the libMySQL.dll which you can find in C:\Program Files\MySQL\MySQL Server 5.0\bin. Once I tried to run my test program I expected to get a "DLL not found" error but the program run showing that anoying error at the end. So my mind naturally went that there might be some conflict with different libMySQL.dll(s) found on my PC. I copied the DLL from the distribution's directory above to the Release directory and run my program again. It worked without errors this time.

Bug#31607 was marked as duplicate of this one.

I'm still not clear on (1) what to do about this error, (2) what are the bad consequences?  Can someone give me an answer?
(1) I use only linux (no windows code to blame), only odbc (no php to blame).
At the moment I use odbc 3.51.22 and mysql server 5.0.18.
Will this problem go away if I move to 5.0.45?  Or to another odbc version?
(2) I understand that the problem causes a 5 sec delay on exit and generates an
annoying message.  I think those things don't actually hurt me.  But if I'm going to run out of memory or threads in the server then this will be a problem.  So what are the other bad consequences?

Bug #32905 was marked as duplicate of this one.

Hi Don.

"(2) I understand that the problem causes a 5 sec delay on exit" ... is described in bug#32366 and will be dealt with in that thread.

As for consequences, they depend on how you use MySQL SW. I have never seen this happening except the way Georg repeated it (CTRL+C in mysql cl window). It would be good to update MySQL server to 5.0.48+ (in my case, it was 5.0.50 that did not exhibit this behavior but I skipped a version or two) and wait for MyODBC "fix" as Jess suggested in bug#32366.

I recently installed PHP 5.2.5 on Windows and the error was still there
(MySQL version 5.0.45). The only way to remove the error was to use old
versions of php_mysql(i).dll or libmysql.dll (<= 5.0.27).

Today I downloaded MySQL 5.0.51 Win32 sources, I compiled the
libmysql.dll library and replaced the one shipped with PHP 5.2.5. This
solved the problem.

Jean-Yves - Any chance that you could post your compiled 5.0.51 limbysql.dll to this bug so that others can test it as well?

The file "libmysql_v5.0.51_bug-data-25621.zip" (see my comment from 7 Dec 14:49 and the request from Christopher Hill [7 Dec 15:23]) has been uploaded to MySQL servers for testing.

I also posted the libmysql.dll v5.0.51 file to http://mysql.oblique.ch/

I downloaded Jean-Yves Délèze's version of libmysql.dll v5.0.51 from http://mysql.oblique.ch/ and tested it on my Windows 2000 VM.

Good news: The error message doesn't come up any more
Bad news: PHP still hangs for about 2 seconds before it closes

Repro steps (as before):

Clean Windows 2000 Professional SP4 in a virtual machine, all security updates
Download php5.2-win32-200712071330.zip from http://snaps.php.net/
Extract to C:\PHP
Append ';C:\PHP' to the PATH environment variable
Add PHPRC environment variable, set to 'C:\PHP\php.ini'
Copy php.ini-recommended to php.ini
	Change the following settings:
		extension_dir = "c:\php\ext\"
		extension=php_mysql.dll
***Copy over updated libmysql.dll (5.0.51)***
Run 'c:\PHP\php-cgi.exe -v'

Returns:
PHP 5.2.6-dev (cgi-fcgi) (built: Dec  7 2007 08:04:20)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
***But still pauses for 2 seconds before returning control to the command line***

As usual, copying over the version of libmysql.dll supplied with PHP 5.2.1 (MySQL Client API version 5.0.22) fixes the pause.

MySQL 5.0.54BK on WinXP localhost does not exhibit the error.

I've just started getting this error, "Error in my_thread_global_end(): 1 thread didn't exit".

I'm running on a Windows 2003 server, IIS6, PHP 5.2.5 and this server does NOT have MySQL of any kind installed on it. All databases are on another server, both MySQL and MsSQL.

I'm using the PHP to get data from Micrsoft SQL 2005.

I have admin rights to all the servers and I have no problems running the script and I don't get the error when I am logged onto a desktop machine.  The error only occurs when a user who doesn't have admin rights logs on and this can be on any desktop PC we have in the office, so its nothing to do with the desktops.

I've seen the solutions about copying an older version of the libmysql.dll file, which I could do, but am a bit reluctant to do so.  So as a temporary measure I just commented out, extension=php_mysql.dll and extension=php_mysqli.dll.  This solved the problem for me.  This is okay at the minute because I don't need to use MySQL from this server yet.

Am just curious as to why it works for me with admin rights and not others. Has anyone else come across the same issue and found a solution, one which doesn't involve using older files?

For php part of problem see http://bugs.php.net/bug.php?id=41350:
[25 Feb 8:50pm UTC] sharadrb at yahoo dot com
Even I had same issue with PHP version 5.2.5. So, I rolled back to older
version 5.2.1 which does not have this issue. Now, I don't have this
issue with version 5.2.1

Also, we haven't updated our pages with the latest PHP - MySQL connector files... To be fixed soon.

C:\php-5.2.5-Win32>php --ri mysql
mysql
MySQL Support => enabled
Active Persistent Links => 0
Active Links => 0
Client API version => 5.0.51a
Directive => Local Value => Master Value
mysql.allow_persistent => On => On
mysql.max_persistent => Unlimited => Unlimited
mysql.max_links => Unlimited => Unlimited
mysql.default_host => no value => no value
mysql.default_user => no value => no value
mysql.default_password => no value => no value
mysql.default_port => no value => no value
mysql.default_socket => no value => no value
mysql.connect_timeout => 60 => 60
mysql.trace_mode => Off => Off

C:\php-5.2.5-Win32>php -r "$c=mysql_connect('localhost','root','tonchika');sleep
(10);"
^C
C:\php-5.2.5-Win32>

Until php 5.2.6 is released please use 5.0.51a community libmysql.dll.
Andrey will post it somewhere (probably on MySQL site) and announce.

The 5 second delay is killing me. 

I need to run PHP scripts from the command line thousands of times.  As I posted in the PHP bug 41350, putting the version 5.0.51a libmysql.dll in C:\Program Files\PHP seemed to eliminate the my_thread_global_end() error message.  And replacing ext\php_mysql.dll and ext\php_mysqli.dll with those from PHP 5.2.1 seemed to stop the 5-second delay when running a simple "php --ini" or hello-world script.  But I still get a 5 second delay if I call mysql_connect() & mysql_close().

-- Bob Stein, VisiBone

P.S. a free PHP (or MySQL) cheatsheet or wall-chart to anyone who helps me get around this.  ;-)

I'm seeing this problem in a totally different setup: on Linux, and without PHP.  Software versions in use:

ii  libmyodbc                      3.51.11-6.1                          the MySQL ODBC driver
ii  libmysqlclient15off            5.0.32-7etch5                        mysql database client library

I assume this problem has been fixed in more recent versions of myodbc and mysqlclient, reporting this for reasons of completeness.

this sounds similar to the problem PHP users are having ... http://bugs.php.net/bug.php?id=41350

Louis, I don't follow you. What is the purpose of your post?  PHP part is tested and is working as expected now. Please see my March 7th post. More discussion available in Bug#32366, for example, and elsewhere in bugsdb.

Bug#28413 was closed as duplicate of this one.

the purpose is that I am getting slow exits when using php 5.2.6. maybe it's fixed for you, but it's not for me.

I can't reproduce that. I installed PHP 5.2.6 as Apache module, loaded the mysql extensions (individually and all together) and did some simple testing using apache's ab tool, loading some script which sometimes creates a mysql connection, sometimes not. That seemed to be the best way to test it, but still all answering times were < 60 ms, which is fine.

Please make sure the correct libmysql is loaded, check this by loading a script "<?php phpinfo(); ?>" using the web. The MySQL categories should mention version 5.0.51a. If that's not the case make sure the correct dll is loaded, I did that by putting libmysql.dll from the PHP distribution to Apache's bin dir.

If it still doesn't work please provide the HTML page created by phpinfo() so we can try to setup a system as close as possible to yours.

test command
(note the -n to ignore php.ini)
	php.exe -n -d enable_dl=On -d extension_dir=ext -f test.php

results with libmysql.dll from php 5.2.6
	start
	PHP Version => 5.2.6
	cURL Information => libcurl/7.16.0 OpenSSL/0.9.8g zlib/1.2.3
	Client API version => 5.0.51a
	end
	(a big pause here)

results with libmysql.dll from php 5.2.1
	start
	PHP Version => 5.2.6
	cURL Information => libcurl/7.16.0 OpenSSL/0.9.8g zlib/1.2.3
	Client API version => 5.0.22
	end
	(no pause here)

test.php 
(note that it only loads the mysql extension - it doesn't even have to connect to a server)
-----------------------
<?php
	echo 'start'."\r\n";

	if (!extension_loaded('mysql'))
		@dl('php_mysql.dll');
	if (!extension_loaded('mysql'))
		die('mysql not loaded');

	if (!extension_loaded('curl'))
		dl('php_curl.dll');
	if (!extension_loaded('curl'))
		die('curl not loaded');
	
	$ch = curl_init('http://localhost');
	curl_setopt($ch,CURLOPT_RETURNTRANSFER,TRUE);
	$res = curl_exec($ch);
	curl_close($ch);
	
	ob_start();
	phpinfo();
	$php_info = ob_get_contents();
	ob_end_clean();
	$php_info = explode("\n",$php_info);
	foreach($php_info as $temp)
	{
		if (strstr($temp,'PHP Version')!==false
			|| strstr($temp,'Client API version')!==false
			|| strstr($temp,'cURL Information')!==false)
			echo trim($temp)."\r\n";
	}

	echo 'end'."\r\n";
?>
-----------------------

5.0.51a community libmysql.dll ?

Can someone give me a link for where to get this file?

Johannes, have you tried using PHP in CGI mode rather than as an Apache module? It seems as if the dev team for both MySQL and PHP are struggling to replicate this, but this might be why. Personally I'm using IIS with php-cgi.exe and seeing the problem every time.

Louis,

thanks for the script. That really helped us to analyze the problem! Let me give you a short explanation of the problem:

Whenever a new thread is created libmysql is told about that by Windows. It then increases a thread counter and initializes some data. When libmysql is being unloaded it checks whether all threads have finished, if not it tries to tell them "close now" and gives them 5 seconds for that. In general this works in a nice way.

Now in your script you're doing a

Louis,

thanks for the script. That really helped us to analyze the problem! Let me give you a short explanation of the problem:

Whenever a new thread is created libmysql is told about that by Windows. It then increases a thread counter and initializes some data. When libmysql is being unloaded it checks whether all threads have finished, if not it tries to tell them "close now" and gives them 5 seconds for that. In general this works in a nice way.

Now in your script you're doing a curl request and curl seems to create an own thread for doing some network stuff but doesn't properly close it. Additionally this thread doesn't listen to libmysql's "finish" request. Therefore libmysql waits till the timeout is reached. That's what oyu are seeing.

We're now working on finding a good solution for that.

Followup in Bug#37226.

This bug should be sorted by now, solution seekers grab this URL http://www.eukhost.com/forums/f15/fix-error-my_thread_global_end-1-threads-didnt-exit-5612...