Description:
MySQL 4.0.8, both compiled my me and the official release version
crashes whenever receiving a network connection from a system without a DNS
entry. Connecting from a system that resolves on reverse (eithor from DNS
or a local hosts file entry) works find. This system is a Slackware 8.1
install with all currect updates. I do not know if this is a mysqld
internal thing or some interaction with the system resolver in glibc 2.2.5,
as unfort even a staticly compiled glibc binary uses the system resolver.
This of course concerns me, there is a large potential for remote
DoS here.
How-To-Repeat:
Install 4.0.8, run the install db script and fire it up. Attempt to
connect from a host that will not reverse resolve. Even a telnet to port
3306 crashed the daemon. The dump from mysqld is included at the bottom of
the message.
Fix:
Unknown
Submitter-Id: [EMAIL PROTECTED]
Originator:
Organization:
MySQL support: none
Synopsis: <synopsis of the problem (one line)>
Severity: serious
Priority: high
Category: mysql
Class: sw-bug
Release: mysql-4.0.8-gamma-standard (Official MySQL-standard binary)
C compiler: 2.95.3
C++ compiler: 2.95.3
Environment:
System: Linux inlet 2.4.20 #2 Tue Dec 24 08:59:29 AKST 2002 i686 unknown
Architecture: i686
Some paths: /usr/bin/perl /usr/bin/make /usr/bin/gmake /usr/bin/gcc /usr/bin/cc
GCC: Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/2.95.3/specs
gcc version 2.95.3 20010315 (release)
Compilation info: CC='gcc' CFLAGS='-O2 -mcpu=pentiumpro' CXX='gcc' CXXFLAGS='-O2
-mcpu=pentiumpro -felide-constructors' LDFLAGS='' ASFLAGS=''
LIBC:
lrwxrwxrwx 1 root root 13 Dec 23 18:45 /lib/libc.so.6 -> libc-2.2.5.so
-rwxr-xr-x 1 root root 1237712 Jul 30 14:15 /lib/libc-2.2.5.so
-rw-r--r-- 1 root root 24984184 Jul 30 12:55 /usr/lib/libc.a
-rw-r--r-- 1 root root 178 Jul 30 12:56 /usr/lib/libc.so
Configure command: ./configure '--prefix=/usr/local/mysql' '--with-comment=Official
MySQL-standard binary' '--with-extra-charsets=complex'
'--with-server-suffix=-standard' '--enable-thread-safe-client' '--enable-local-infile'
'--enable-assembler' '--disable-shared' '--with-client-ldflags=-all-static'
'--with-mysqld-ldflags=-all-static' '--with-innodb' 'CFLAGS=-O2 -mcpu=pentiumpro'
'CXXFLAGS=-O2 -mcpu=pentiumpro -felide-constructors' 'CXX=gcc'
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=33554432
read_buffer_size=131072
sort_buffer_size=1048568
max_used_connections=0
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections =
147967 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x8717a50
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=0xbfe7f608, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x806f3bb
0x8269928
0x807724c
0x8077665
0x82670dc
0x829c67a
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/U/s/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=1
Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 1 did to cause the crash. In some cases of really
bad corruption, the values shown above may be invalid.
The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
information that should help you find out what is causing the crash.
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
