Bug #17135 'Signal 11' on remote conections
Submitted: 5 Feb 2006 16:35 Modified: 13 Feb 2006 2:36
Reporter: Stolz Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:mysql-4.1.14 OS:Linux (Gentoo Linux)
Assigned to: CPU Architecture:Any

[5 Feb 2006 16:35] Stolz
Description:
Whenever I try to conect remotely to my server, mysqld gets signal 11.

I've tried with several clients (MySQLfront, lcd4linux, mysqlnavigator,MySQL Connector/ODBC, MySQL Query Browser,mysql++,...) on several OS and always get the same error. It only happens when trying to connect from remote hosts, connecting form localhost works well. All clients used to work like a charm some days ago and I dont' remember to have done any change on my server so I don't understand what can happened.

here is the log:
=========================
InnoDB: !!!!!!!!!!!!!! UNIV_DEBUG switched on !!!!!!!!!!!!!!!
060205 17:16:40  InnoDB: Started; log sequence number 0 46952
/usr/sbin/mysqld: ready for connections.
Version: '4.1.14-debug-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Gentoo Linux mysql-4.1.14
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=16777216
read_buffer_size=258048
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 92780 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=(nil)
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=0xbfb1dc98, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x814e1a6
0xffffe420
New value of fp=0x100 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 tra
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
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.
InnoDB: !!!!!!!!!!!!!! UNIV_DEBUG switched on !!!!!!!!!!!!!!!
InnoDB: Warning: we did not need to do crash recovery, but log scan
InnoDB: progressed past the checkpoint lsn 0 46952 up to lsn 0 46988
060205 17:16:44  InnoDB: Started; log sequence number 0 46952
/usr/sbin/mysqld: ready for connections.
Version: '4.1.14-debug-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Gentoo Linux mysql-4.1.14

How to repeat:
Try to establish a remote connection to mysqld
[5 Feb 2006 23:25] Hartmut Holzgraefe
Sounds like a DNS resolve problem. 
Does the problem go away when you start with --skip-name-resolve?
Do you have BDB tables enabled (SHOW STATUS LIKE 'HAVE_BDB') 
and entries using 'db' in your /etc/nsswitch.conf?
Or does increasing the tread_stack parameter to 256K help?
[6 Feb 2006 16:41] Stolz
Thanks for your answer

>Sounds like a DNS resolve problem. 
>Does the problem go away when you start with --skip-name-resolve?
No, still the same error.

>Do you have BDB tables enabled (SHOW STATUS LIKE 'HAVE_BDB') 
>and entries using 'db' in your /etc/nsswitch.conf?
I've 'db' entries in /etc/nsswitch.conf but BDB tables are disabled:
mysql> SHOW STATUS LIKE 'HAVE_BDB';
Empty set (0.00 sec)

>Or does increasing the tread_stack parameter to 256K help?
It didn't help. I've added it into my my.cnf but it didn't help, still the same error.
[6 Feb 2006 16:45] Hartmut Holzgraefe
>> Do you have BDB tables enabled (SHOW STATUS LIKE 'HAVE_BDB') 
>> and entries using 'db' in your /etc/nsswitch.conf?
> I've 'db' entries in /etc/nsswitch.conf but BDB tables are disabled:
> mysql> SHOW STATUS LIKE 'HAVE_BDB';
> Empty set (0.00 sec)

sorry, it is SHOW VARIABLES LIKE 'HAVE_BDB', not SHOW STATUS ...
could you check this again please?
[6 Feb 2006 17:05] Stolz
So I do have it enabled:
mysql> SHOW VARIABLES LIKE 'HAVE_BDB';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| have_bdb      | YES   |
+---------------+-------+
1 row in set (0.00 sec)

Here are the 'db' entries, but I don't know how to proceed to resolv the problem, any help would be apreciated:
# grep db /etc/nsswitch.conf
# passwd:    db files nis
# shadow:    db files nis
# group:     db files nis
services:    db files
protocols:   db files
rpc:         db files
ethers:      db files

T.I.A
[6 Feb 2006 17:16] Hartmut Holzgraefe
Ok, so this is a duplicate of bug #11047 and #16286 then

http://bugs.mysql.com/11047
http://bugs.mysql.com/16286
[6 Feb 2006 18:22] Stolz
After reading bug #11047, as far as I can understand, I think mine is different scenario. I'm using x86, not PPC and I've compiled MySQL without Berkeley DB support. Despite it, I've tried the /etc/nsswitch.conf workaround commented there, but it didn't work.

Anyway, I'll subcribe to bug #11047.
[6 Feb 2006 18:26] Hartmut Holzgraefe
As SHOW VARIABLES shows

  | have_bdb      | YES   |

you do have bdb compiled in ...
[6 Feb 2006 18:39] Stolz
You are right. I've forgot to comment I've recompiled mysql and now I'dont have bdb support and the error is still there:

mysql> SHOW VARIABLES LIKE 'HAVE_BDB';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| have_bdb      | NO    |
+---------------+-------+
1 row in set (0.03 sec)

Thanks for your interest.
[6 Feb 2006 18:45] Hartmut Holzgraefe
ok, not a duplicate then ...
[8 Feb 2006 8:55] Valeriy Kravchuk
Is it possible that you updated your glibc somehow? Please, try to install the latest 4.1.18 version, now generally available. Inform about the results.
[13 Feb 2006 2:36] Stolz
With 4.1.18-r30 the problem has gone :)

Thanks