Bug #67263 mysql aborted suddenly and restart faild
Submitted: 16 Oct 2012 12:10 Modified: 16 Nov 2012 12:25
Reporter: yang kavin Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server: Errors Severity:S2 (Serious)
Version:5.5.9 OS:Linux (Redhat 5.3 x64)
Assigned to: CPU Architecture:Any
Tags: Assertion failure in thread, mysqld got signal 6

[16 Oct 2012 12:10] yang kavin
Description:
mysql server aborted suddenly , and restart it  Failure。

121016 15:43:29 [ERROR] /app/soft/mysql/bin/mysqld: Sort aborted
121016 17:47:13  InnoDB: Assertion failure in thread 1124407616 in file /root/mysql-5.5.9/storage/innobase/ibuf/ibuf0ibuf.c line 4147
InnoDB: Failing assertion: page_get_n_recs(page) > 1
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
121016 17:47:13 - mysqld got signal 6 ;
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=8388608
max_used_connections=503
max_threads=1500
thread_count=71
connection_count=71
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 36913818 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
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...
stack_bottom = (nil) thread_stack 0x30000
/app/soft/mysql/bin/mysqld(my_print_stacktrace+0x33)[0x75bd73]
/app/soft/mysql/bin/mysqld(handle_segfault+0x36e)[0x4e7bce]
/lib64/libpthread.so.0[0x383c80e4c0]
/lib64/libc.so.6(gsignal+0x35)[0x383bc30215]
/lib64/libc.so.6(abort+0x110)[0x383bc31cc0]
/app/soft/mysql/bin/mysqld[0x865316]
/app/soft/mysql/bin/mysqld[0x868b7e]
/app/soft/mysql/bin/mysqld[0x827ef8]
/app/soft/mysql/bin/mysqld[0x84fdc9]
/app/soft/mysql/bin/mysqld[0x7e79b8]
/lib64/libpthread.so.0[0x383c806367]
/lib64/libc.so.6(clone+0x6d)[0x383bcd30ad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
pure virtual method called
terminate called without an active exception
121016 17:47:14 mysqld_safe Number of processes running now: 0
121016 17:47:14 mysqld_safe mysqld restarted
121016 17:47:14 InnoDB: The InnoDB memory heap is disabled
121016 17:47:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins
121016 17:47:14 InnoDB: Compressed tables use zlib 1.2.3
121016 17:47:14 InnoDB: Initializing buffer pool, size = 2.0G
121016 17:47:14 InnoDB: Completed initialization of buffer pool
121016 17:47:14 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 367437081660
121016 17:47:14  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 367441972943
121016 17:47:14  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 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 924281864, file name ./mysql-bin.000690
121016 17:47:15  InnoDB: Waiting for the background threads to start
121016 17:47:16 InnoDB: 1.1.5 started; log sequence number 367441972943
121016 17:47:16  InnoDB: Assertion failure in thread 1120008512 in file /root/mysql-5.5.9/storage/innobase/ibuf/ibuf0ibuf.c line 4147
InnoDB: Failing assertion: page_get_n_recs(page) > 1
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
121016 17:47:16 - mysqld got signal 6 ;
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=8388608
max_used_connections=0
max_threads=1500
thread_count=0
connection_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 36913818 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

How to repeat:
I am not find anything cause that,so i have no testcase 

Suggested fix:
it's ok that  i update the mysql server from 5.5.9 to 5.5.28.
[16 Oct 2012 12:25] MySQL Verification Team
Please try last version. Thanks.
[17 Nov 2012 1:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".