Bug #3003 mysqld got signal 11
Submitted: 28 Feb 2004 10:28 Modified: 1 Mar 2004 6:03
Reporter: Donny Simonton Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:4.1.1 OS:Linux (Linux 2.6.2)
Assigned to: CPU Architecture:Any

[28 Feb 2004 10:28] Donny Simonton
Description:
Over the past 2 days, MySQL on my slave server has died and restarted, below you will find three different err logs entries about each one of them.  I've included my.cnf.  This box has been running without any problems for the past month.  The box is a dual proc 3.06 xeon with hyperthreading with 2 gigs of memory.  I know we aren't supposed to turn on swap, but we did anyway and it's set to 4 gigs, but it's never been used before.

Besides this box being a slave server, it also acts as a secondary database server for databases that are not needed on the master server.

After the third time I reinstalled the rpms of 4.1.1 with rpm -F, just to make sure that isn't the problem.  But I haven't restarted mysql since all of the tables are still being fixed.

Please, any suggestions would be appreciated.  And I do have a mysql support contract.

Thanks.

Donny

********* First time *************

040227 17:50:25  /usr/sbin/mysqld: Normal shutdown

040227 17:50:25  Aborted connection 49 to db: 'mysql' user: 'phpmyadmin' host: `parking-slave-backend.directnic.com' (Got timeout reading communication packets)
040227 17:50:25  Slave I/O thread killed while reading event
040227 17:50:25  Slave I/O thread exiting, read up to log 'parking-master-bin.000096', position 16014498
040227 17:50:25  Aborted connection 112 to db: 'mysql' user: 'phpmyadmin' host: `parking-slave-backend.directnic.com' (Got timeout reading communication packets)
040227 17:50:25  Aborted connection 99 to db: 'mysql' user: 'phpmyadmin' host: `parking-slave-backend.directnic.com' (Got timeout reading communication packets)
040227 17:50:25  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
Aborted connection 110 to db: 'mysql' user: 'phpmyadmin' host: `parking-slave-backend.directnic.com' (Got timeout reading communication packets)
max_used_connections=47
max_connections=500
threads_connected=20
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1153068 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x86376d0
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=0xbfe1f638, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8089167
0x82da818
040227 17:50:25  Aborted connection 29 to db: 'test' user: 'phpmyadmin' host: `parking-slave-backend.directnic.com' (Got timeout reading communication packets)
0x83014e9
0x8301383
0x82b7046
0x82b7639
0x8094940
0x82d7fcc
0x830b8fa
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/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) 040227 17:50:25  Aborted connection 73 to db: 'mysql' user: 'phpmyadmin' host: `parking-slave-backend.directnic.com' (Got timeout reading communication packets)
 is invalid pointer
thd->thread_id=11
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.
040227 17:50:26  Slave SQL thread exiting, replication stopped in log  'parking-master-bin.000094' at position 660174650

Number of processes running now: 0
040227 17:52:28  mysqld restarted
040227 17:52:29  Warning: Asked for 196608 thread stack, but got 126976
/usr/sbin/mysqld: ready for connections.
Version: '4.1.1-alpha-standard-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306

********* Second time *************

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=136
max_connections=500
threads_connected=113
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1153068 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x60c90088
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=0xbf49f638, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8089167
0x82da818
0x83014e9
0x8301383
0x82b7046
0x82b7639
0x8094940
0x82d7fcc
0x830b8fa
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/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=156
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.

Number of processes running now: 0
040227 23:53:15  mysqld restarted
040227 23:53:15  Warning: Asked for 196608 thread stack, but got 126976
/usr/sbin/mysqld: ready for connections.
Version: '4.1.1-alpha-standard-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306

********* Third time (this morning) *************
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.

Number of processes running now: 1
mysqld process hanging, pid 1926 - killed
040228 09:37:21  mysqld restarted
040228  9:37:21  Warning: Asked for 196608 thread stack, but got 126976
/usr/sbin/mysqld: ready for connections.
Version: '4.1.1-alpha-standard-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306

********* Resolve Stack Dump *************

I ran a resolve_stack_dump on #1 and #2 and this is what I got:

0x8089167 handle_segfault + 423
0x82da818 pthread_sighandler + 184
0x83014e9 chunk_free + 297
0x8301383 free + 147
0x82b7046 my_no_flags_free + 22
0x82b7639 free_root + 153
0x8094940 handle_one_connection + 608
0x82d7fcc pthread_start_thread + 220
0x830b8fa thread_start + 4

********* my.cnf  *************
##
##  Intercosmos MySQL configuration
##  For MySQL 4.x versions
##
##

[client]
port           = 3306
socket         = /var/lib/mysql/mysql.sock

[mysqld]
port           = 3306
socket         = /var/lib/mysql/mysql.sock
skip-locking
datadir        = /www/mysql
log-warnings
# We dont need innodb.
skip-innodb

open-files-limit=36864
set-variable   = max_connect_errors=500
set-variable   = max_connections=400

ft_min_word_len=3
# Who knows.
set-variable   = key_buffer_size=256M

# Used for ORDER BY or GROUP BY operations
#set-variable   = sort_buffer=8M
set-variable = sort_buffer_size=16M
set-variable = read_rnd_buffer_size=4M

# table_cache should be max_connections * number of joins.
set-variable   = table_cache=1024

#No actual reason.
set-variable   = thread_cache_size=8

# Set as big as the largest blob.
set-variable   = max_allowed_packet=8M

set-variable   = read_buffer_size=2M

# Try number of CPU's*2 for thread_concurrency
set-variable    = thread_concurrency=8
set-variable    = myisam_sort_buffer_size=64M

[mysqld]
server-id=3

#In theory will kick all connections every hour.
set-variable    = interactive_timeout=3600
set-variable    = wait_timeout=3600

set-variable   = query_cache_size=8M
tmpdir         = /tmp
myisam-recover = BACKUP,FORCE

log-long-format
log-slow-queries
set-variable    = long_query_time=3

[mysqldump]
quick
set-variable   = max_allowed_packet=16M

[mysql]
no-auto-rehash

[myisamchk]
set-variable    = key_buffer=256M
set-variable    = sort_buffer=256M
set-variable    = read_buffer=2M
set-variable    = write_buffer=2M

[mysqlhotcopy]
interactive-timeout

How to repeat:
Well, this is the third time this happened in the past 2 days.  I'm repairing the tables for the third time and with over 50 gigs of data it takes about 3 hours to complete.  So this is getting annoying really fast.
[28 Feb 2004 11:54] MySQL Verification Team
Hi!

This is not replication related problem.

Are you using Red Hat ??

We were forced to increase thread_stack to 196K due to some very well known
glibc problems on the latest Red Hat's.

But MySQL is not capable to allocate required thread stack on your system:

 Warning: Asked for 196608 thread stack, but got 126976
/usr/sbin/mysqld: ready for connections.

This could be a cause of  problems. Please check your ulimit settings. 

You also seem to be using NPTL, which are very unstable and low performing.

Our benchmark team has tested those thoroughly , and came with conclusion that 
they can not be yet recommended for production.

The solution to your problem could be quite easy. Unlike our RPM distro, which 
is dynamic, our tarball binary distro makes MySQL server statically.

Can you please try just replacing mysqld binary from our binary tarball ??

This should take away a problem, as then MySQL would not be dependent on glibc and NPTL.

FYI 4.1.2 should be out in 10 - 15 days.
[28 Feb 2004 12:03] Donny Simonton
Sinisa - thanks for the information, yes I will try the binary to see how that works and see if it solves the problem.

Also I am using fedora core 1, with linux kernel 2.6.2 right now.

I will let you know after switching to the binary if I have any additional problems.  Thanks again.
[28 Feb 2004 12:07] MySQL Verification Team
You are welcome.

If you continue to have problems, please open an issue at our CSC WWW interface at: 

https://support.mysql.com

That way all your info will stay confidential.

The same for any other problem / question you encounter.

You can also write to support@... if you wish .... ;o)
[28 Feb 2004 12:11] Donny Simonton
Sinisa,
One more thing, can I just be lazy and copy everything from the tar.gz /bin directory for the binary and not have to completely install the entire binary?  Since it won't be pathed correctly everywhere else?

Basically extract the binary, then just move the /bin files to the same location that the rpm installs them?  Then all I will need to do is restart mysql.  

If I can do this, do I need to copy anything else?  Or would that be it?

Thanks

Donny
[28 Feb 2004 12:16] MySQL Verification Team
Yes, you can do that.

YOu can do even less then that.

Just copy mysqld binary itself. 

Nothing else !!!

Please check that it is in /bin subdirectory and not in libexec/ subdirectory.

I do not follow very much how binary distros are packed. 

Sorry ............... ;o)
[28 Feb 2004 12:43] Donny Simonton
One more heads up, I had to copy mysqld to the /usr/sbin directory, I tried to restart it and it failed because it was looking in the wrong location for the messagefiles.

In my case, I went into my.cnf and added:
language        =/usr/share/mysql/english

Restarted everything and so far it's working just fine.  Hopefully it will last the night.  Thanks again!
[28 Feb 2004 12:46] MySQL Verification Team
You are welcome.

Keep us posted.
[1 Mar 2004 6:37] Donny Simonton
Just a final update on this, this seems to have solved the problem that we were having thanks again for all of the help.

Donny
[11 Jun 2009 4:53] Amit Lamba
Hey Sinisa,

Can you please provide me with our binary ? So that I can also install the same as I am also getting the same error.
my id is : amit.lamba@buongiorno.com

Thanks,
Amit