Description:
051118 01:49:28 mysqld started
051118 1:49:28 InnoDB: Started; log sequence number 0 43655
051118 1:49:28 [Note] Recovering after a crash using mysql-bin
051118 1:49:28 [Note] Starting crash recovery...
051118 1:49:28 [Note] Crash recovery finished.
051118 1:49:28 [Warning] mysql.user table is not updated to new password format; Disabling new password usage until mysql_fix_privilege_tables is run
051118 1:49:28 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.15-standard-log' socket: '/home/mysql/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL)
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=8388608
read_buffer_size=1044480
max_used_connections=1
max_connections=50
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 110391 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x8a2d478
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=0xaec02b94, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8156750
0xb75acdf8
0x8a76b70
0x837d455
0x837dc10
0x81941de
0x818a4a4
0x83833c3
0x81b89a6
0x81a951a
0x819aa4a
0x819b20e
0x8197700
0x816bd61
0x8172880
0x8169d03
0x816983d
0x8168d48
0xb75a6dac
0xb74e09ea
New value of fp=(nil) 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 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 0x8a552a8 = create table report2(IBU varchar(50),Region varchar(50),ibubranch varchar(50),customer varchar(50), complainnature varchar(50), total varchar(50) ) as SELECT complain1.IBU, complain1.region,complain1.ibubranch , complain1.customer , complain1.complainnature ,Count(*) AS total FROM complain1 GROUP BY complain1.region, complain1.IBU,complain1.ibubranch, complain1.customer, complain1.complainnature
thd->thread_id=1 The manual page at http://www.mysql.com/doc/en/Crashing.html containsinformation that should help you find out what is causing the crash.
The error log shows the complete backtrace. I resolved the stack dump to the
following:
0x8156750 set_info__7sp_headPcUixxP14st_sp_chisticsUl + 100
0xb75acdf8 _end + -1359017700
0x8a76b70 _end + 4957844
0x837d455 __15Item_func_fieldRt4List1Z4Item + 69
0x837dc10 __17Item_func_bit_negP4Item + 20
0x81941de row_ins_foreign_report_add_err + 2110
0x818a4a4 ibuf_get_volume_buffered + 948
0x83833c3 fix_length_and_dec__13Item_str_conv + 3
0x81b89a6 pars_select_statement + 182
0x81a951a row_sel_build_prev_vers_for_mysql + 42
0x819aa4a row_unlock_for_mysql + 246
0x819b20e row_mysql_freeze_data_dictionary + 346
0x8197700 row_ins_duplicate_error_in_clust + 1776
0x816bd61 dict_table_add_to_cache + 565
0x8172880 dict_foreign_parse_drop_constraints + 1172
0x8169d03 dict_create_add_foreigns_to_dictionary + 2575
0x816983d dict_create_add_foreigns_to_dictionary + 1353
0x8168d48 dict_create_or_check_foreign_constraint_tables + 404
0xb75a6dac _end + -1359042352
0xb74e09ea _end + -1359854322
mysql> select @@global.key_buffer_size ,@@global.read_buffer_size ,@@global.sort_buffer_size,@@global.max_connections;
+--------------------------+---------------------------+---------------------------+--------------------------+
| @@global.key_buffer_size | @@global.read_buffer_size | @@global.sort_buffer_size | @@global.max_connections |
+--------------------------+---------------------------+---------------------------+--------------------------+
| 8388608 | 1044480 | 1048568 | 50 |
+--------------------------+---------------------------+---------------------------+--------------------------+
1 row in set (0.00 sec)
How to repeat:
Seems to happen at random. I don't know if this is due to a hardware problem
(bad memory - segmentation fault).Also please see the output of top -C for this system
02:04:44 up 12:01, 5 users, load average: 0.00, 0.00, 0.00
79 processes: 78 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: cpu user nice system irq softirq iowait idle
total 0.0% 0.5% 0.0% 0.0% 0.0% 0.0% 99.3%
Mem: 4114240k av, 940464k used, 3173776k free, 0k shrd, 209380k buff
389636k active, 428752k inactive
Swap: 8191976k av, 0k used, 8191976k free 543368k cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
5752 root 25 10 13196 12M 8744 S N 0.5 0.3 3:08 2 rhn-applet-gui
1 root 15 0 508 508 452 S 0.0 0.0 0:04 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/0
8 root 39 19 0 0 0 SWN 0.0 0.0 0:00 1 ksoftirqd/1
9 root 34 19 0 0 0 SWN 0.0 0.0 0:00 2 ksoftirqd/2
10 root 34 19 0 0 0 SWN 0.0 0.0 0:00 3 ksoftirqd/3
13 root 25 0 0 0 0 SW 0.0 0.0 0:00 2 bdflush
11 root 15 0 0 0 0 SW 0.0 0.0 0:00 1 kswapd
12 root 15 0 0 0 0 SW 0.0 0.0 0:00 1 kscand
14 root 15 0 0 0 0 SW 0.0 0.0 0:01 1 kupdated
15 root 25 0 0 0 0 SW 0.0 0.0 0:00 2 mdrecoveryd
21 root 25 0 0 0 0 SW 0.0 0.0 0:00 2 scsi_eh_0
24 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kjournald
