MySQL Bugs: #7094: Segfault with corrupted frm file

Bug #7094	Segfault with corrupted frm file
Submitted:	8 Dec 2004 5:15	Modified:	8 Jan 2005 21:09
Reporter:	Bill McCaffrey	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	4.1.7-standard	OS:	ses8
Assigned to:		CPU Architecture:	Any

Description:
Segfault occurs on "show table status" when there is a corrupted frm file. Table data is stored in innodb engine. Server recognizes that the frm file is bad but still crashes. When the file was removed, the server is fine.

Here is the dump from the log -

041207 20:18:34 [ERROR] /usr/local/mysql/bin/mysqld: Incorrect information in file: './neopets/new_hiscores2.frm'
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=536870912
read_buffer_size=2093056
max_used_connections=2
max_connections=1000
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 421976 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x956d7d0
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=0xbfe3e208, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x808af93
0x82d6de8
0x82f3726
0x82f3613
0x82aa2b6
0x82aa92c
0x80b8a88
0x80b46d5
0x80b3909
0x80b4a89
0x810f9e7
0x809c29e
0x809e6e9
0x8098def
0x8098778
0x8097eb7
0x82d459c
0x82fdf1a
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 0x957ebf0 = show table status
thd->thread_id=3
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.

How to repeat:
Use the attached frm file and run "show table status" or any query using this table name.

Bill,

please resolve the stack trace.

How did you end up with a corrupt .frm file?

Regards,

Heikki

Here is the stack trace -

0x808af93 handle_segfault + 423
0x82d6de8 pthread_sighandler + 184
0x82f3726 chunk_free + 214
0x82f3613 free + 147
0x82aa2b6 my_no_flags_free + 22
0x82aa92c free_root + 120
0x80b8a88 openfrm__FPCcT0UiUiUiP8st_table + 6184
0x80b46d5 open_unireg_entry__FP3THDP8st_tablePCcN22 + 581
0x80b3909 open_table__FP3THDPCcN21Pb + 933
0x80b4a89 open_ltable__FP3THDP13st_table_list13thr_lock_type + 69
0x810f9e7 mysqld_extend_show_tables__FP3THDPCcT1 + 3155
0x809c29e mysql_execute_command__FP3THD + 9626
0x809e6e9 mysql_parse__FP3THDPcUi + 169
0x8098def dispatch_command__F19enum_server_commandP3THDPcUi + 1643
0x8098778 do_command__FP3THD + 188
0x8097eb7 handle_one_connection + 615
0x82d459c pthread_start_thread + 220
0x82fdf1a thread_start + 4

The frm file corrupted due to a hardware fault. The affected server was a backup replica, so we did a hot backup of the primary and restored the database. This particular table had been dropped sometime between the crash and the hot backup so when the files were copied, it was not overwritten.

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".