Description:
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.
key_buffer_size=536870912
read_buffer_size=2093056
max_used_connections=1
max_connections=50
threads_connected=0
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.
thd=0xccf5d0
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:
0x746f6f72
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
thd->thread_id=6
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.
or
Add hosts to /etc/hosts
