Description:
I awoke yesterday morning to hear that some users were unable to access their database tables. Namely, I found corruption in the tables as well as messages that existing clients had them open, even after shutting down the MySQL daemon to repair them. The repair of all affected tables went by without a hitch, however this crash in itself is likely something to report. I tried the same query again and again following this and could not reproduce the crash using this query stated in the logs. The server has been up 360 days and the MySQL daemon about 2 months- so it doesn't seem to be a reoccuring problem. Nonetheless, a bug is a bug, as any database engine should crash as little as possible.
The server includes a RAID-5 array for storage of database files (making corruption less likely), and also includes redundant ECC memory (making memory errors slightly less likely).
Error log follows...
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=12582912
read_buffer_size=131072
max_used_connections=825
max_connections=825
threads_connected=620
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1866873 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 620 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=0x4564a588
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=0xbdfbdb98, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8070740
0x8247998
0x825a951
0x8247d29
0x825ad70
0x82bf598
0x82bf5bd
0x82c0076
0x82c0245
0x82bf3ac
0x80bf259
0x80bc13f
0x80958a1
0x80962f6
0x8094427
0x8093bd6
0x807b2d0
0x807ebda
0x807a3d3
0x8079e2d
0x8079669
0x824514c
0x827b17a
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 0x8fef358 = SELECT u.username, u.user_id, u.user_level, u.user_posts, u.user_from, u.user_website, u.user_email, u.user_icq, u.user_aim, u.user_yim, u.user_regdate, u.user_msnm, u.user_viewemail, u.user_rank, u.user_sig, u.user_sig_bbcode_uid, u.user_avatar, u.user_avatar_type, u.user_allowavatar, u.user_allowsmile, p.*, pt.post_text, pt.post_subject, pt.bbcode_uid, u.user_sigson, u.user_avatarson
FROM boards_posts p, boards_users u, boards_posts_text pt
WHERE p.topic_id = 259713
AND pt.post_id = p.post_id
AND u.user_id = p.poster_id
ORDER BY p.post_time ASC
LIMIT 0, 12
thd->thread_id=26566740
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.
Fatal signal 11 while backtracing
Number of processes running now: 2
040719 03:08:34 mysqld restarted
[ some messages about recovering InnoDB ]
and various... for assorted DBs.
040719 4:18:49 read_key: Got error 127 when reading table './database/table''
How to repeat:
Can't seem to get a repeat instance. Just hoping on making MySQL that much better and maybe this would be useful to help do so.
Suggested fix:
Unknown
Description: I awoke yesterday morning to hear that some users were unable to access their database tables. Namely, I found corruption in the tables as well as messages that existing clients had them open, even after shutting down the MySQL daemon to repair them. The repair of all affected tables went by without a hitch, however this crash in itself is likely something to report. I tried the same query again and again following this and could not reproduce the crash using this query stated in the logs. The server has been up 360 days and the MySQL daemon about 2 months- so it doesn't seem to be a reoccuring problem. Nonetheless, a bug is a bug, as any database engine should crash as little as possible. The server includes a RAID-5 array for storage of database files (making corruption less likely), and also includes redundant ECC memory (making memory errors slightly less likely). Error log follows... 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=12582912 read_buffer_size=131072 max_used_connections=825 max_connections=825 threads_connected=620 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1866873 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 620 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=0x4564a588 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=0xbdfbdb98, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8070740 0x8247998 0x825a951 0x8247d29 0x825ad70 0x82bf598 0x82bf5bd 0x82c0076 0x82c0245 0x82bf3ac 0x80bf259 0x80bc13f 0x80958a1 0x80962f6 0x8094427 0x8093bd6 0x807b2d0 0x807ebda 0x807a3d3 0x8079e2d 0x8079669 0x824514c 0x827b17a 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 0x8fef358 = SELECT u.username, u.user_id, u.user_level, u.user_posts, u.user_from, u.user_website, u.user_email, u.user_icq, u.user_aim, u.user_yim, u.user_regdate, u.user_msnm, u.user_viewemail, u.user_rank, u.user_sig, u.user_sig_bbcode_uid, u.user_avatar, u.user_avatar_type, u.user_allowavatar, u.user_allowsmile, p.*, pt.post_text, pt.post_subject, pt.bbcode_uid, u.user_sigson, u.user_avatarson FROM boards_posts p, boards_users u, boards_posts_text pt WHERE p.topic_id = 259713 AND pt.post_id = p.post_id AND u.user_id = p.poster_id ORDER BY p.post_time ASC LIMIT 0, 12 thd->thread_id=26566740 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. Fatal signal 11 while backtracing Number of processes running now: 2 040719 03:08:34 mysqld restarted [ some messages about recovering InnoDB ] and various... for assorted DBs. 040719 4:18:49 read_key: Got error 127 when reading table './database/table'' How to repeat: Can't seem to get a repeat instance. Just hoping on making MySQL that much better and maybe this would be useful to help do so. Suggested fix: Unknown