Description:
The Category is a bit of a guess, I've never done anything with mysql before...
MySQL is not able to start at all. The mysqld_safe script is spinning in a loop during startup reporting a signal 11 error, but no "proper" error message to explain what is going wrong:
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: 071231 16:52:01 InnoDB: Started; log sequence number 0 43665
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: mysqld got signal 11;
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: This could be because you hit a bug. It is also possible that this binary
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: or one of the libraries it was linked against is corrupt, improperly built,
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: or misconfigured. This error can also be caused by malfunctioning hardware.
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: We will try our best to scrape up some info that will hopefully help diagnose
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: the problem, but since we have already crashed, something is definitely wrong
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: and this may fail.
Dec 31 16:52:01 twoshoes-gig mysqld[16184]:
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: key_buffer_size=16777216
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: read_buffer_size=131072
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: max_used_connections=0
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: max_connections=100
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: threads_connected=0
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: It is possible that mysqld could use up to
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 233983 K
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: bytes of memory
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: Hope that's ok; if not, decrease some variables in the equation.
Dec 31 16:52:01 twoshoes-gig mysqld[16184]:
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: thd=0x8ac64a0
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: Attempting backtrace. You can use the following information to find out
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: where mysqld died. If you see no messages after this, something went
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: terribly wrong...
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: Cannot determine thread, fp=0xbf98d118, backtrace may not be correct.
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: Stack range sanity check OK, backtrace follows:
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: 0x81c0619
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: 0x8203d08
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: 0x81fc158
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: 0x81fd6c4
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: 0x81fdd35
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: 0x81fe04d
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: 0x824f02f
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: 0x825005b
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: 0x81c2e0a
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: 0xb7c29ebc
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: 0x8139d71
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: New value of fp=(nil) failed sanity check, terminating stack trace!
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: stack trace is much more helpful in diagnosing the problem, so please do
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: resolve it
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: Trying to get some variables.
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: Some pointers may be invalid and cause the dump to abort...
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: thd->query at (nil) is invalid pointer
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: thd->thread_id=0
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Dec 31 16:52:01 twoshoes-gig mysqld[16184]: information that should help you find out what is causing the crash.
Dec 31 16:52:01 twoshoes-gig mysqld_safe[16200]: Number of processes running now: 0
Dec 31 16:52:01 twoshoes-gig mysqld_safe[16202]: restarted
Dec 31 16:52:01 twoshoes-gig mysqld_safe[16212]: ended
Dec 31 16:52:01 twoshoes-gig mysqld[16205]: 071231 16:52:01 InnoDB: Started; log sequence number 0 43665
Dec 31 16:52:01 twoshoes-gig mysqld[16205]: mysqld got signal 11;
[repeats forever]
Stack trace shows the following:
# resolve_stack_dump -s /tmp/mysqld.sym -n /tmp/mysqld.stack
0x81c0619 handle_segfault + 681
0x8203d08 openfrm(THD*, char const*, char const*, unsigned int, unsigned int, unsigned int, st_table*) + 7848
0x81fc158 insert_fields(THD*, Name_resolution_context*, char const*, char const*, List_iterator<Item>*, bool) + 1912
0x81fd6c4 open_table(THD*, st_table_list*, st_mem_root*, bool*, unsigned int) + 1764
0x81fdd35 open_tables(THD*, st_table_list**, unsigned int*, unsigned int) + 533
0x81fe04d simple_open_n_lock_tables(THD*, st_table_list*) + 93
0x824f02f acl_reload(THD*) + 271
0x825005b acl_init(bool) + 187
0x81c2e0a main + 1466
0xb7c29ebc _end + -1353445108
0x8139d71 _start + 33
I ran various forms of "myisamchk" including (AFAIK) the most complete checking "myisamchk -e -r /var/lib/mysql/*/*.MYI". There were initially errors corrected (which unfortunately I didn't save, as I'm a complete MySQL newbie) but it now checks cleanly repeatedly but still won't start.
The database is for MythTV, so not terribly large or complex, and it seems pretty serious that the code is segfaulting on startup.
Since mysqld could't start up I wasn't able to try any of the resolutions that involve dropping tables. I tried moving the whole /var/lib/mysql/mythconverg directory out of the way, but I was still unable to start mysqld.
Eventually, I accessed another installation of MythTV and copied the /var/lib/mysql/mysql files over to this system and was able to restart mysqld, so it appears some corruption in the tables in .../mysql was causing the crash, but myisamchk couldn't detect or fix it.
How to repeat:
I'm unsure of the original source of corruption, but I was repeatedly rebooting the system to diagnose another system startup problem. I will attach the original corrupted files (which are very small), in case that would help diagnose the problem.
