Bug #24866 Server crashes after client disconnect if thread_cache_siize > 0
Submitted: 6 Dec 2006 19:43 Modified: 7 Jan 2007 7:42
Reporter: Joe Anthony Email Updates:
Status: No Feedback Impact on me:
Category:MySQL Server Severity:S2 (Serious)
Version:5.0.27 OS:Linux (CentOS Linux 2.6)
Assigned to: CPU Architecture:Any
Tags: /etc/hosts, dns, linux, thread_cache

[6 Dec 2006 19:43] Joe Anthony
I'm having a problem when a mysql client running disconnects from a mysql server with the thread_cache_size set > 0 and the clients IP is not listed in /etc/hosts. 

It only happens after the first client disconnects. It seems any number of clients can connect and disconnect while the first client is still connected. Once the first client disconnects the server will crash on the next disconnect.

If the client is listed in the servers /etc/hosts file, the server doesn't not crash, regardless if the client has a reverse/forward DNS entries.  

I've tested this with both mysql 5.0.24a and 5.0.27. 

Have tried using both CentOs 4.3/4.4  on both server and client. Also tried on 2.6.9, and 2.6.16-xen. 

All my test enviroments are either Dual Core AMD Opteron, or dual proc AMD Opterons

> uname -a
Linux db6 2.6.16-xen #1 SMP Sun Apr 9 23:11:36 BST 2006 x86_64 x86_64 x86_64 GNU/Linux

> uname -a
Linux db1.buzznet.com 2.6.9-42.0.3.ELsmp #1 SMP Fri Oct 6 06:28:26 CDT 2006 x86_64 x86_64 x86_64 GNU/Linux

> uname -a
Linux page2 2.6.9-42.0.3.plus.c4smp #1 SMP Fri Oct 6 11:42:04 CDT 2006 x86_64 x86_64 x86_64 GNU/Linux

> uname -a
Linux page3 2.6.9-34.ELsmp #1 SMP Thu Mar 9 06:23:23 GMT 2006 x86_64 x86_64 x86_64 GNU/Linux

Server version  5.0.27-debug-log
Built with:
gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)

mysqld output:
sudo /usr/local/mysql/libexec/mysqld --basedir=/usr/local/mysql --datadir=/data1/mysql --pid-file=/data1/mysql/db6.pid --skip-external-locking --socket=/tmp/mysql.sock --skip-grant-tables --user=mysql --debug -T 

mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 831287 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0x2b0416b21d28, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
New value of fp=0xccf5d0 failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at (nil)  is invalid pointer
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

How to repeat:
Set thread_cache_size > 0  on the server. 

Remove any /etc/hosts entries for the client IP. 

Suggested fix:
Turn off thread caching.  
Add hosts to /etc/hosts
[7 Dec 2006 7:42] Valeriy Kravchuk
Thank you for a problem report. Please, try to repeat with a newer kernel (2.6.17 at least) and glibc (2.3.9, for example - I do not see your glibc version in the report), and inform about the results.
[8 Jan 2007 0: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".