Bug #13995 mysqld got signal 11;
Submitted: 13 Oct 2005 8:10 Modified: 17 Oct 2005 10:53
Reporter: Tawatchai Doungbal Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server Severity:S2 (Serious)
Version:4.0.18-Max-log OS:Linux (RedHat 9)
Assigned to: CPU Architecture:Any

[13 Oct 2005 8:10] Tawatchai Doungbal
Description:
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=209715200
read_buffer_size=1044480
max_used_connections=299
max_connections=300
threads_connected=265
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 817997 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

You seem to be running 32-bit Linux and have 265 concurrent connections.
If you have not changed STACK_SIZE in LinuxThreads and built the binary
yourself, LinuxThreads is quite likely to steal a part of the global heap for
the thread stack. Please read http://www.mysql.com/doc/L/i/Linux.html

thd=0x8c3792c8
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=0x89df1dac, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80db9d4
0x400b6618
(nil)
0x837a216
0x8364738
0x835e210
0x835d194
0x835cdbb
0x8131898
0x810a6e7
0x8108f36
0x8108c23
0x81008f7
0x80ff596
0x80e6a12
0x80ea455
0x80e5b33
0x80e557e
0x80e4da8
0x400b12b6
0x420de407
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 0x9c18090 = select count(NameT),person.* from CENTRAL.person group by NameT
thd->thread_id=6024
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.
051012 16:25:06  /usr/sbin/mysqld-max: Normal shutdown

051012 16:29:29  mysqld started
051012 16:29:32  InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 14 3079418698
InnoDB: Doing recovery: scanned up to log sequence number 14 3079418698
InnoDB: Last MySQL binlog file position 0 52776348, file name ./chm2svr-bin.056
051012 16:29:32  InnoDB: Flushing modified pages from the buffer pool...
051012 16:29:32  InnoDB: Started
/usr/sbin/mysqld-max: ready for connections.
Version: '4.0.18-Max-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306

How to repeat:
HardWare : IBM xSeries 345, RAM:2GB, Xeon:3.06GH
OS: RedHat 9

my.cnf
-------------------------------------------------------------
[client]
default-character-set=tis620
port            = 3306
socket          = /var/lib/mysql/mysql.sock

[mysqld]
default-character-set=tis620
port            = 3306
datadir=/data
socket          = /var/lib/mysql/mysql.sock
skip-external-locking
set-variable    = key_buffer=200M
set-variable    = max_allowed_packet=1M
set-variable    = table_cache=512
set-variable    = read_buffer_size=1M
set-variable    = sort_buffer=1M
#set-variable   = thread_cache=8

set-variable    = max_connections=300
set-variable    = thread_concurrency=8
set-variable    = myisam_sort_buffer_size=64M
log-bin
server-id       = 1

innodb_data_file_path = ibdata1:20G;ibdata2:10M:autoextend
innodb_data_home_dir = /data/ibdata
innodb_log_group_home_dir = /data/iblog
innodb_log_arch_dir = /data/iblog
set-variable = innodb_mirrored_log_groups=1
set-variable = innodb_log_files_in_group=3
set-variable = innodb_log_file_size=800M
set-variable = innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=1
innodb_log_archive=0
set-variable = innodb_buffer_pool_size=780M
set-variable = innodb_additional_mem_pool_size=20M
set-variable = innodb_file_io_threads=4
set-variable = innodb_lock_wait_timeout=50

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

[mysql]
no-auto-rehash

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

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

[mysqlhotcopy]
interactive-timeout
---------------------------------------------------------------
This error has been the serious problem to my applications,cause mysqld-service will restart.
Please, some one complete this error for me.

thank you.

Suggested fix:
I do not know how does error occur...
but my idea for solve this error that 'increase RAM' or other ways?
[13 Oct 2005 8:28] Valeriy Kravchuk
Thank you for a problem report. I noted the following in your configuration:

set-variable = innodb_log_buffer_size=8M
set-variable = innodb_buffer_pool_size=780M
set-variable = innodb_additional_mem_pool_size=20M

So, you may use additional 800+ M of RAM. With 800+ reported, this may give you not enough memory... So, please, send also the results of "top" command performed while server is under the usual load. Send also the results of "ulimit -a" command performed by the user running mysqld.

Do you have both MyISAM and InnoDB tables really used? How many simultaneous connections do you have really? Can you figure out, what statements were performed when you got this error and crash?

Can you also try to use newer version of MySQL? 4.0.26 is available for some time from our site. Your 4.0.18 is really old.
[13 Oct 2005 9:39] Tawatchai Doungbal
This error will occur with don't have top statement. show step by step:
---------------------------------------<step previous error and mysql shutdow>
051007 20:10:54  /usr/sbin/mysqld-max: Normal shutdown

051007 20:15:16  mysqld started
051007 20:15:18  InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 14 2445152010
InnoDB: Doing recovery: scanned up to log sequence number 14 2445152010
InnoDB: Last MySQL binlog file position 0 95157133, file name ./chm2svr-bin.055
051007 20:15:19  InnoDB: Flushing modified pages from the buffer pool...
051007 20:15:19  InnoDB: Started
/usr/sbin/mysqld-max: ready for connections.
Version: '4.0.18-Max-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306
-----------------------------------------<step last error occur>----------------
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=209715200
read_buffer_size=1044480
max_used_connections=299
max_connections=300
threads_connected=265
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 817997 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

You seem to be running 32-bit Linux and have 265 concurrent connections.
If you have not changed STACK_SIZE in LinuxThreads and built the binary
yourself, LinuxThreads is quite likely to steal a part of the global heap for
the thread stack. Please read http://www.mysql.com/doc/L/i/Linux.html

thd=0x8c3792c8
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=0x89df1dac, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80db9d4
0x400b6618
(nil)
0x837a216
0x8364738
0x835e210
0x835d194
0x835cdbb
0x8131898
0x810a6e7
0x8108f36
0x8108c23
0x81008f7
0x80ff596
0x80e6a12
0x80ea455
0x80e5b33
0x80e557e
0x80e4da8
0x400b12b6
0x420de407
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 0x9c18090 = select count(NameT),person.* from CENTRAL.person group by NameT
thd->thread_id=6024
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.
051012 16:25:06  /usr/sbin/mysqld-max: Normal shutdown

051012 16:29:29  mysqld started
051012 16:29:32  InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 14 3079418698
InnoDB: Doing recovery: scanned up to log sequence number 14 3079418698
InnoDB: Last MySQL binlog file position 0 52776348, file name ./chm2svr-bin.056
051012 16:29:32  InnoDB: Flushing modified pages from the buffer pool...
051012 16:29:32  InnoDB: Started
/usr/sbin/mysqld-max: ready for connections.
Version: '4.0.18-Max-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306
[13 Oct 2005 9:48] Valeriy Kravchuk
"top" is a Linux command, not a MySQL statement. It should be executed from a separate terminal, while mysql is running. It will give you a screen of results similar to the following:

 12:43:31  up  3:13,  2 users,  load average: 1,92, 1,05, 0,63
49 processes: 45 sleeping, 4 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
           total   91,8%    0,0%    8,1%   0,0%     0,0%    0,0%    0,0%
Mem:   223124k av,  189508k used,   33616k free,       0k shrd,   31232k buff
        79724k active,              90196k inactive
Swap:  586332k av,   12352k used,  573980k free                  125196k cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
16114 openxs    25   0   596  596   368 S     2,1  0,2   0:00   0 sed
15373 openxs    25   0  1120 1120  1012 S     1,1  0,5   0:00   0 sh
16028 openxs    17   0  1120 1120   888 R     0,3  0,5   0:00   0 top
 1644 openxs    16   0  1384 1176  1176 S     0,1  0,5   0:00   0 sshd
16116 openxs    25   0   444  444   340 R     0,1  0,1   0:00   0 sed
...

Just copy and paste them, or redirect top output to some file. The first part, about the memory used and available, is what I need.

What about the other questions I asked you?
[13 Oct 2005 9:52] Tawatchai Doungbal
Next that I have to observe some variables and point to be a big question that
InnoDB-Data File Size(innodb_data_file_path = ibdata1:20G;ibdata2:10M:autoextend
) 
on ibdata1 is 20G; either is it too larger than InnoDB support? or Can RedHat9 support big file size?

I don't have an exprience too solve this error. Please help.
Thank you.
[13 Oct 2005 9:58] Tawatchai Doungbal
when i'm run command 'top' the resualt will follow:

# Uncomment the following if you are using Innobase tables
 16:49:21  up 1 day, 20 min,  2 users,  load average: 0.07, 0.21, 0.29
69 processes: 68 sleeping, 1 running, 0 zombie, 0 stopped
 16:50:36  up 1 day, 21 min,  2 users,  load average: 0.11, 0.19, 0.27
69 processes: 67 sleeping, 2 running, 0 zombie, 0 stopped
 16:51:06  up 1 day, 22 min,  2 users,  load average: 0.20, 0.21, 0.27
69 processes: 68 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states:   0.0% user   0.0% system    0.0% nice   0.0% iowait 100.0% idle
CPU1 states:   0.0% user   0.0% system    0.0% nice   0.0% iowait 100.0% idle
CPU2 states:   0.0% user   0.0% system    0.0% nice   0.0% iowait 100.0% idle
CPU3 states:   0.0% user   0.0% system    0.0% nice   0.0% iowait 100.0% idle
Mem:  2581496k av, 2568620k used,   12876k free,       0k shrd,   57192k buff
                   2030756k actv,       0k in_d,   57684k in_c
Swap: 1024088k av,  512556k used,  511532k free                 1529208k cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
    1 root      15   0    88   64    40 S     0.0  0.0   0:05   0 init
    2 root      RT   0     0    0     0 SW    0.0  0.0   0:00   0 migration/0
    3 root      RT   0     0    0     0 SW    0.0  0.0   0:00   1 migration/1
    4 root      RT   0     0    0     0 SW    0.0  0.0   0:00   2 migration/2
    5 root      RT   0     0    0     0 SW    0.0  0.0   0:00   3 migration/3
    6 root      15   0     0    0     0 SW    0.0  0.0   0:00   3 keventd
    7 root      34  19     0    0     0 SWN   0.0  0.0   0:00   0 ksoftirqd_CPU0
    8 root      34  19     0    0     0 SWN   0.0  0.0   0:00   1 ksoftirqd_CPU1
    9 root      34  19     0    0     0 SWN   0.0  0.0   0:00   2 ksoftirqd_CPU2
   10 root      34  19     0    0     0 SWN   0.0  0.0   0:00   3 ksoftirqd_CPU3
   15 root      15   0     0    0     0 SW    0.0  0.0   0:01   1 bdflush
   11 root      15   0     0    0     0 SW    0.0  0.0   1:08   2 kswapd
   12 root      15   0     0    0     0 SW    0.0  0.0   0:00   3 kscand/DMA
   13 root      16   0     0    0     0 SW    0.0  0.0   1:48   1 kscand/Normal
   14 root      16   0     0    0     0 SW    0.0  0.0   6:04   1 kscand/HighMem
   16 root      15   0     0    0     0 SW    0.0  0.0   0:01   0 kupdated
   17 root      25   0     0    0     0 SW    0.0  0.0   0:00   0 mdrecoveryd
   23 root      25   0     0    0     0 SW    0.0  0.0   0:00   0 scsi_eh_0
   25 root      21   0     0    0     0 SW    0.0  0.0   0:00   1 scsi_eh_1
   28 root      15   0     0    0     0 SW    0.0  0.0   0:11   3 kjournald
   86 root      25   0     0    0     0 SW    0.0  0.0   0:00   0 khubd
  725 root      15   0     0    0     0 SW    0.0  0.0   0:00   1 kjournald
  757 root      15   0     0    0     0 SW    0.0  0.0   0:10   1 kjournald
  766 root      15   0     0    0     0 SW    0.0  0.0   0:00   1 kjournald
 1523 root      15   0   188  160   112 S     0.0  0.0   0:00   0 syslogd
 1527 root      15   0    48   40     0 S     0.0  0.0   0:00   2 klogd
 1545 rpc       15   0    72    0     0 SW    0.0  0.0   0:00   1 portmap
 1564 rpcuser   25   0    84    0     0 SW    0.0  0.0   0:00   1 rpc.statd
 1644 root      16   0   672  596   428 S     0.0  0.0   0:00   1 sshd
 1658 root      15   0   116    4     0 S     0.0  0.0   0:00   2 xinetd
 1668 root      15   0    84   56    36 S     0.0  0.0   0:01   3 gpm
 1677 root      15   0   156  140    88 S     0.0  0.0   0:00   2 crond
 1688 root      15   0   896  536   392 S     0.0  0.0   0:09   2 cupsd
 1728 root      25   0   176    4     0 S     0.0  0.0   0:00   3 mysqld_safe
 1764 mysql     15   0  915M 876M  2720 S     0.0 34.7 158:36   0 mysqld-max
[13 Oct 2005 10:06] Valeriy Kravchuk
There is no limitation on data file size in InnoDB other than implied by the file system used (see http://dev.mysql.com/doc/refman/5.0/en/innodb-configuration.html)

So, please, send the results of the following Linux commands:

df -k
ls -l /data/ibdata

Please, note, that this is not a support forum for MySQL, but a bug database. And nobody will not be able to help you until you start answering the questions you were asked.
[13 Oct 2005 10:31] Tawatchai Doungbal
[root@chm2svr root]# df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2             59363460  25877068  30470816  46% /
/dev/sda1               100692     15128     80365  16% /boot
/dev/sdb1            211676108  28307232 172616336  15% /data
/dev/sda3             10080364   1173400   8394900  13% /home
none                   1290748         0   1290748   0% /dev/shm
[root@chm2svr root]# ls -l /data/ibdata
total 21002280
-rw-rw----    1 mysql    mysql    21474836480 Oct 13 17:20 ibdata1
-rw-rw----    1 mysql    mysql    10485760 Oct  4 22:03 ibdata2
[13 Oct 2005 13:33] Valeriy Kravchuk
Thank you for the additional information. So, you have that 20G file already, as well as plenty of free space in /data. It is not a problem.

But according to the "top" results, you have only 12M of RAM left, with 511M available for swap, and that all with mysqld-max using 915 M only (and still working). As we identified the theoretical ability for it to use much more, I think, you should try to reduce the amount of memory dedicated to InnoDB:

That is, try to run with, say

set-variable = innodb_buffer_pool_size=200M

and inform me about any crash in such a configuration with smaller memory "footprint". Adding more RAM is an option too.

In the meantime, what about the other questions I asked:

1. Send also the results of "ulimit -a" command performed by the user running mysqld.

2. Do you have both MyISAM and InnoDB tables really used? 

3. How many simultaneous connections do you have really?  (I saw 265 in the error log, is it usual?)

4. Can you figure out, what statements were performed when you got this error and crash?

5. Do you have any plans to upgrade to 4.0.26? I'll use only latest version for verification, in any case.
[14 Oct 2005 7:16] Tawatchai Doungbal
I can't change my.cnf because now are actual work time. After work time i going to change and send resault for you again.

but i show you following

[root@chm2svr data]# footprint
-bash: footprint: command not found

[root@chm2svr data]# ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 7168
virtual memory        (kbytes, -v) unlimited
[14 Oct 2005 7:41] Tawatchai Doungbal
Answer question:
1:[root@chm2svr data]# ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 7168
virtual memory        (kbytes, -v) unlimited
-------------------------------------------------------
2:Yes, My System use both MyISAM and InnoDB actualy. Do you have some comment? 
-------------------------------------------------------
3:Everage connection about 260 per/day, to 290 at heavy time. 
-------------------------------------------------------
4:It is unexpected error, when i have got error so mysql-service will restart autometic and system show me 'Lost Connection.'.
Some time mysql-service can't start, I'm only reboot server.
-------------------------------------------------------
5:I ever test update MySQL server to 4.0.26 with RPM on other server, system show me following statement:
MySQL-server-4.0.26-0 requires perl(DB)
MySQL-server-4.0.26-0 requires perl(Data::Dumper)
MySQL-server-4.0.26-0 requires perl(File::Temp)
MySQL-server-4.0.26-0 requires perl(POSIX)
MySQL-server-4.0.26-0 requires perl(Sys-Hostname)
MySQL-server-4.0.26-0 requires perl(strict)
MySQL-server-4.0.26-0 requires perl(vars)

please advise me to update. thank you.
[14 Oct 2005 12:09] Valeriy Kravchuk
Thank you for the additional information.

Your ulimit -a looks OK for me.

I asked a question about engines used to be able to provide additiona advices on memory-related server variables setting.

> 3:Everage connection about 260 per/day, to 290 at heavy time. 

You mean, up to 290 connections at any given time? So, you max_connections setting is correct.

> 5:I ever test update MySQL server to 4.0.26 with RPM on other server, system show me following statement: ...

Looks like you have to install perl as RPM package. Please, check, if it is installed. It is used for test suite only, though. Then, repeat the installation of MySQL 4.0.26 RPM.

Please, inform me about the results of work with changed my.cnf. I'll think about other possible changes. Can you install additional RAM on the server?
[15 Oct 2005 8:16] Heikki Tuuri
Hi!

Please resolve the stack dump that is printed in a crash.

Please run CHECK TABLE on CENTRAL.person
[17 Oct 2005 6:58] Tawatchai Doungbal
my.cnf max_connections=300

I will show you with
some system resault when i'm reduce  innodb_buffer_pool_size=200M are following :
--------
FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O tInnoDB: ###### Diagnostic info printed to the standard output
hread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (write thread)
Pending normal aio reads: 0, aio writes: 0,
 ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
402719 OS file reads, 39021 OS file writes, 14390 OS fsyncs
0.25 reads/s, 16384 avg bytes/read, 2.06 writes/s, 1.06 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf for space 0: size 1, free list len 177, seg size 179,
9864 inserts, 9864 merged recs, 5381 merges
Hash table size 830173, used cells 170553, node heap has 188 buffer(s)
3397.98 hash searches/s, 210.86 non-hash searches/s
---
LOG
---
Log sequence number 14 3147643644
Log flushed up to   14 3147643644
Last checkpoint at  14 3147634888
0 pending log writes, 0 pending chkp writes
11174 log i/o's done, 0.94 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 261885090; in additional pool allocated 6958336
Buffer pool size   12800
Free buffers       0
Database pages     12612
Modified db pages  19
Pending reads 2
Pending writes: LRU 0, flush list 0, single page 0
Pages read 2491676, created 352, written 29264
0.25 reads/s, 0.06 creates/s, 1.19 writes/s
Buffer pool hit rate 1000 / 1000
--------------
ROW OPERATIONS
--------------
4 queries inside InnoDB, 0 queries in queue
Main thread process no. 1772, id 1415453120, state: sleeping
Number of rows inserted 5435, updated 15875, deleted 1431, read 167064401
1.19 inserts/s, 1.37 updates/s, 0.00 deletes/s, 19153.74 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
InnoDB: Warning: a long semaphore wait:
--Thread 1633457728 has waited at ../../innobase/btr/../include/btr0btr.ic line 28 for 626.00 seconds the semaphore:
S-lock on RW-latch at 415e9bc4 created in file buf0buf.c line 444
a writer (thread id 1656916928) has reserved it in mode exclusive
number of readers 0, waiters flag 1
Last time read locked in file btr0pcur.c line 228
Last time write locked in file buf0buf.c line 1404
InnoDB: Error: semaphore wait has lasted > 600 seconds
InnoDB: We intentionally crash the server, because it appears to be hung.
051017 11:08:37  InnoDB: Assertion failure in thread 1407064640 in file sync0arr.c line 934
InnoDB: Failing assertion: 0
InnoDB: We intentionally generate a memory trap.
InnoDB: Send a detailed bug report to mysql@lists.mysql.com
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=209715200
read_buffer_size=1044480
max_used_connections=228
max_connections=300
threads_connected=226
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 817997 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

You seem to be running 32-bit Linux and have 226 concurrent connections.
If you have not changed STACK_SIZE in LinuxThreads and built the binary
yourself, LinuxThreads is quite likely to steal a part of the global heap for
the thread stack. Please read http://www.mysql.com/doc/L/i/Linux.html

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=0x53de10fc, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80db9d4
0x400b6618
(nil)
0x400b12b6
0x420de407
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
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: Thread 1656520640 stopped in file ha_innodb.cc line 391
InnoDB: Thread 1647449024 stopped in file ha_innodb.cc line 391
InnoDB: Thread 1659966656 stopped in file ha_innodb.cc line 391

Number of processes running now: 0
051017 11:08:38  mysqld restarted
051017 11:08:38  InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 14 3147645641
InnoDB: Doing recovery: scanned up to log sequence number 14 3147646799
051017 11:08:38  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 4474719, file name ./chm2svr-bin.059
051017 11:08:39  InnoDB: Flushing modified pages from the buffer pool...
051017 11:08:39  InnoDB: Started
/usr/sbin/mysqld-max: ready for connections.
Version: '4.0.18-Max-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306
[17 Oct 2005 6:59] Tawatchai Doungbal
when run 'top' command
--------------------------------------------------------------------------------------------------------------------
 11:23:53  up 1 day,  2:15,  2 users,  load average: 1.09, 0.56, 0.38
68 processes: 67 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states:   0.3% user   1.1% system    0.0% nice   0.0% iowait  98.0% idle
CPU1 states:   7.1% user   0.2% system    0.0% nice   0.0% iowait  92.1% idle
CPU2 states:   2.4% user   1.4% system    0.0% nice   0.0% iowait  95.0% idle
CPU3 states:  21.3% user   1.1% system    0.0% nice   0.0% iowait  76.4% idle
Mem:  2581496k av, 2569636k used,   11860k free,       0k shrd,   51968k buff
                   2080672k actv,    3332k in_d,   58168k in_c
Swap: 1024088k av,   12428k used, 1011660k free                 2126956k cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
 3680 mysql     15   0  258M 258M  3800 S    36.5 10.2   3:17   2 mysqld-max
 1806 root      15   0   792  280   180 S     0.1  0.0   0:00   3 smbd
 3874 root      15   0  1064 1064   856 R     0.1  0.0   0:00   2 top
    1 root      15   0    88   64    40 S     0.0  0.0   0:05   1 init
    2 root      RT   0     0    0     0 SW    0.0  0.0   0:00   0 migration/0
    3 root      RT   0     0    0     0 SW    0.0  0.0   0:00   1 migration/1
    4 root      RT   0     0    0     0 SW    0.0  0.0   0:00   2 migration/2
    5 root      RT   0     0    0     0 SW    0.0  0.0   0:00   3 migration/3
    6 root      15   0     0    0     0 SW    0.0  0.0   0:00   2 keventd
    7 root      34  19     0    0     0 SWN   0.0  0.0   0:00   0 ksoftirqd_CPU0
    8 root      34  19     0    0     0 SWN   0.0  0.0   0:00   1 ksoftirqd_CPU1
    9 root      34  19     0    0     0 SWN   0.0  0.0   0:00   2 ksoftirqd_CPU2
   10 root      34  19     0    0     0 SWN   0.0  0.0   0:00   3 ksoftirqd_CPU3
   15 root      25   0     0    0     0 SW    0.0  0.0   0:00   0 bdflush
   11 root      15   0     0    0     0 SW    0.0  0.0   0:31   0 kswapd
   12 root      15   0     0    0     0 SW    0.0  0.0   0:00   0 kscand/DMA
   13 root      16   0     0    0     0 SW    0.0  0.0   0:33   0 kscand/Normal
   14 root      16   0     0    0     0 SW    0.0  0.0   4:18   2 kscand/HighMem
   16 root      15   0     0    0     0 SW    0.0  0.0   0:02   3 kupdated
   17 root      25   0     0    0     0 SW    0.0  0.0   0:00   0 mdrecoveryd
   23 root      25   0     0    0     0 SW    0.0  0.0   0:00   0 scsi_eh_0
   25 root      21   0     0    0     0 SW    0.0  0.0   0:00   1 scsi_eh_1
   28 root      15   0     0    0     0 SW    0.0  0.0   0:11   3 kjournald
   86 root      25   0     0    0     0 SW    0.0  0.0   0:00   0 khubd
  831 root      15   0     0    0     0 SW    0.0  0.0   0:00   0 kjournald
  881 root      15   0     0    0     0 SW    0.0  0.0   0:04   1 kjournald
  885 root      15   0     0    0     0 SW    0.0  0.0   0:00   1 kjournald
 1526 root      15   0   184  156   112 S     0.0  0.0   0:00   0 syslogd
 1530 root      15   0    52   44     0 S     0.0  0.0   0:00   2 klogd
 1548 rpc       15   0    76    0     0 SW    0.0  0.0   0:00   0 portmap
 1567 rpcuser   25   0    80    0     0 SW    0.0  0.0   0:00   2 rpc.statd
 1647 root      15   0   376  300   136 S     0.0  0.0   0:00   0 sshd
 1661 root      15   0   116   12     0 S     0.0  0.0   0:00   2 xinetd
 1671 root      15   0    80   52    36 S     0.0  0.0   0:01   0 gpm
 1680 root      15   0   152  132    88 S     0.0  0.0   0:00   3 crond
 1691 root      15   0   904  544   392 S     0.0  0.0   0:09   3 cupsd
 1731 root      21   0   532  484   352 S     0.0  0.0   0:00   0 mysqld_safe
 1793 xfs       15   0  2460  224    64 S     0.0  0.0   0:00   1 xfs
 1810 root      15   0   976  524   396 S     0.0  0.0   0:03   3 nmbd
 1829 daemon    15   0   180  164   120 S     0.0  0.0   0:00   2 atd
 1837 root      23   0    48    4     0 S     0.0  0.0   0:00   1 mingetty
 1838 root      23   0    48    4     0 S     0.0  0.0   0:00   1 mingetty
 1839 root      23   0    48    4     0 S     0.0  0.0   0:00   1 mingetty
 1840 root      23   0    48    4     0 S     0.0  0.0   0:00   1 mingetty
 1841 root      23   0    48    4     0 S     0.0  0.0   0:00   1 mingetty
 1842 root      23   0    48    4     0 S     0.0  0.0   0:00   2 mingetty
 1843 root      15   0   636    0     0 SW    0.0  0.0   0:00   0 gdm-binary
 1886 root      16   0   768  184     0 S     0.0  0.0   0:00   0 gdm-binary
--------------------------------------------------------------------------------------------------------------
[root@chm2svr root]# ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 7168
virtual memory        (kbytes, -v) unlimited
-----------------------------------------------------------------------------------------------------------------
when run 'top' again
-----------------------------------------------------------------------------------------------------------------
 13:46:48  up 1 day,  4:38,  2 users,  load average: 0.23, 0.22, 0.18
68 processes: 67 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states:   0.0% user   0.1% system    0.0% nice   0.0% iowait  99.4% idle
CPU1 states:   0.0% user   0.0% system    0.0% nice   0.0% iowait 100.0% idle
CPU2 states:   6.1% user   0.1% system    0.0% nice   0.0% iowait  93.3% idle
CPU3 states:   0.0% user   0.1% system    0.0% nice   0.0% iowait  99.4% idle
Mem:  2581496k av, 2568544k used,   12952k free,       0k shrd,   60388k buff
                   2022740k actv,   47412k in_d,   57460k in_c
Swap: 1024088k av,   27440k used,  996648k free                 2103696k cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
 3680 mysql     15   0  273M 273M  3800 S     6.4 10.8  20:52   3 mysqld-max
 3894 root      15   0  1068 1068   856 R     0.2  0.0   0:11   3 top
    1 root      15   0    88   64    40 S     0.0  0.0   0:05   0 init
    2 root      RT   0     0    0     0 SW    0.0  0.0   0:00   0 migration/0
    3 root      RT   0     0    0     0 SW    0.0  0.0   0:00   1 migration/1
    4 root      RT   0     0    0     0 SW    0.0  0.0   0:00   2 migration/2
    5 root      RT   0     0    0     0 SW    0.0  0.0   0:00   3 migration/3
    6 root      15   0     0    0     0 SW    0.0  0.0   0:00   3 keventd
    7 root      34  19     0    0     0 SWN   0.0  0.0   0:00   0 ksoftirqd_CPU0
    8 root      34  19     0    0     0 SWN   0.0  0.0   0:00   1 ksoftirqd_CPU1
    9 root      34  19     0    0     0 SWN   0.0  0.0   0:00   2 ksoftirqd_CPU2
   10 root      34  19     0    0     0 SWN   0.0  0.0   0:00   3 ksoftirqd_CPU3
   15 root      25   0     0    0     0 SW    0.0  0.0   0:00   0 bdflush
---------------------------------------------------------------------------------------------------------------------------
[root@chm2svr root]# ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 7168
virtual memory        (kbytes, -v) unlimited
[17 Oct 2005 7:01] Tawatchai Doungbal
Dear Heikki Tuuri
    Table CENTRAL.person is InnoDB Type. Can't run CHECK TABLE 

Thank You
[17 Oct 2005 10:53] Valeriy Kravchuk
Your last log snippet looks very similar to a bug report http://bugs.mysql.com/bug.php?id=5898. 

According to it, the bug giving this assertion failure is fixed in 4.0.22. You are using 4.0.18. So, please, try to use newer version, 4.0.26, as I recommended you before. Do not hesitate to inform about the problems with it, if any.