Description of problem:
mysqld/safe_mysqld segfault whenever a connection is made thru internet (or
outside it's network) with a 56kbps connection.
Version-Release number of selected component (if applicable):
both source and binary
Steps to Reproduce:
1.service mysqld stop
2.su - mysql
3./usr/bin/safe_mysqld --defaults-file=/etc/my.cnf >/dev/null 2>&1 &
4.then try to connect at port 3306 with mysql or telnet it would drop the
connection and segfault.
----Server side result:
/usr/bin/safe_mysqld: line 278: 23776 Segmentation fault $NOHUP_NICENESS
$ledir/$MYSQLD $defaults --basedir=$MY_BASEDIR_VERSION --datadir=$DATADIR
$USER_OPTION --pid-file=$pid_file --skip-locking >>$err_log 2>&1
----Client Side result:
ERROR 2013: Lost connection to MySQL server during query
spawns to mysql monitor environment
it is always replicable on both default binary and recompiled binaries
from original source from redhat
One quick solution is to put the ip address of the client to /etc/hosts of
Downfall of the solution, you can't add a non static ip address of clients
from time to time. I used a dialup connection and my ip address is not static.
Is there a solution or patch to the mysql source?
This bug is reproducible even to the new compiled version of mysql 4.0.9
Haven't tested yet on 4.1 alpha.
I hope this won't result on remote exploitation.
This is fixed in glibc, but the current rawhide version might be just too
much NPTL-based to be usable on RHL 8.0. Search bugzilla for previous reports
of the same issue (on both RHL 8.0 and 7.3).
BTW, NEEDINFO means that the RH developers want input from you, not the
other way around. Setting it to NEEDINFO may result in getting ignored ;-)
Thank you for the tips miloslav and correction. I hope I could use
bugzilla more efficient as much as possible so not to duplicate reports.
I just browse from previous reports and found this
That solves the problem on my box. I don't know if that would
work for others. As I had read from other reports the problem might
be from the new glibc although I don't understand why some
programmers try to resolve from ip to name on a tcp/ip handshake of
a database daemon. If I am not mistaken redhat syslogd or perhaps other
daemons already or may have done that and output it at the log file.
Oh well I just wonder.... Correct me if I'm confused.
*** This bug has been marked as a duplicate of 74943 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.