MySQL segfault with mismatched charsets - mysql

Question

I recently rsync a bunch of MYI, MYD, and FRM files from one MySQL 5.0.95 server to another, both using MyISAM. Due to a forgotten hot-fix, it turns out that the original database was configured to default tables to utf8, and the new database was set to latin1. When we turned on the new database, it worked, but shortly thereafter, several queries caused it to segfault multiple times in a row. I suspect it has to do with the charset difference, but I don't understand the stack trace well enough to get to the bottom of the issue. Below is the decoded stack trace, and then the mysql.log.
Stack trace:
0x819b416 handle_segfault + 806
0xb76246a1 _end + -1358137335
0x8193936 Protocol::store_string_aux(char const*, unsigned int, charset_info_st*, charset_info_st*) + 166
0x8193a2b Protocol_simple::store(Field*) + 139
0x818f671 select_send::send_data(List<Item>&) + 161
0x81e5735 init_read_record_seq(st_join_table*) + 373
0x81e8629 join_read_always_key_or_null(st_join_table*) + 2153
0x81ecbc7 sub_select(JOIN*, st_join_table*, bool) + 135
0x81ef127 JOIN::rollup_write_data(unsigned int, st_table*) + 2487
0x81ff6ed JOIN::exec() + 1341
0x81fc72b _Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select + 219
0x82015a6 handle_select(THD*, st_lex*, select_result*, unsigned long) + 326
0x81b1240 mysql_execute_command(THD*) + 7728
0x81b6140 mysql_parse(THD*, char const*, unsigned int, char const**) + 640
0x81b88d0 dispatch_command(enum_server_command, THD*, char*, unsigned int) + 3408
0x81b9f30 handle_one_connection + 2624
0xb785f10f _end + -1355799945
0xb767c74e _end + -1357776714
mysql.log:
160623 17:39:52 - 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=209715200
read_buffer_size=262144
max_used_connections=4
max_connections=1500
threads_connected=4
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3660800 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x86799f8
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=0xa648d168, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x819b416
0xb75d56a1
0x8193936
0x8193a2b
0x818f671
0x81e5735
0x81e8629
0x81ecbc7
0x81ef127
0x81ff6ed
0x81fc72b
0x82015a6
0x81b1240
0x81b6140
0x81b88d0
0x81b9f30
0xb781010f
0xb762d74e
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 0x875aaf0 = SELECT * FROM Data_197_21268_1 ORDER BY ID LIMIT 1
thd->thread_id=8
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.
Thank you in advance for any help you can offer. Also, I know I have to upgrade MySQL, this is in the works.