MySQL Bugs: #29459: server died handling latin2 collate latin2_czech

Bug #29459	server died handling latin2 collate latin2_czech_cs
Submitted:	30 Jun 2007 18:51	Modified:	5 Dec 2007 19:07
Reporter:	Shane Bester (Platinum Quality Contributor)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Charsets	Severity:	S1 (Critical)
Version:	6.0.1-BK, 6.0.3	OS:	Any
Assigned to:	Alexander Barkov	CPU Architecture:	Any
Tags:	crash

Description:
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=8388572
read_buffer_size=131072
max_used_connections=1
max_threads=151
threads_connected=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337602 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x8e58f40
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=0x42a8a9ac, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x820fa3b handle_segfault + 541
0x859e1c8 my_strnxfrm_czech + 214
0x83a4178 _Z15falcon_strnxfrmPvPKcjS1_j + 62
0x83f9e8f _ZN14MySQLCollation7makeKeyEP5ValueP8IndexKeyi + 303
0x83ee3de _ZN5Index7makeKeyEPN3Nfs5FieldEP5ValueiP8IndexKey + 128
0x83ee533 _ZN5Index7makeKeyEiPP5ValueP8IndexKey + 115
0x83eeee7 _ZN5Index7makeKeyEP6RecordP8IndexKey + 301
0x83bab39 _ZN5Table18checkUniqueIndexesEP11TransactionP13RecordVersion + 145
0x83bbbc3 _ZN5Table6insertEP11TransactionP6Stream + 247
0x83ac56f _ZN15StorageDatabase6insertEP10ConnectionP5TableP6Stream + 39
0x83b09e7 _ZN12StorageTable6insertEv + 59
0x83a60eb _ZN16StorageInterface9write_rowEPh + 253
0x82fd975 _ZN7handler12ha_write_rowEPh + 33
0x828e3f0 _Z12write_recordP3THDP8st_tableP12st_copy_info + 1712
0x831e7a9 _Z14read_sep_fieldP3THDR12st_copy_infoP13st_table_listR4ListI4ItemES8_S8_R9READ_INFOR6Stringmb + 1269
0x831d8aa _Z10mysql_loadP3THDP12sql_exchangeP13st_table_listR4ListI4ItemES8_S8_15enum_duplicatesbb + 3658
0x821f478 _Z21mysql_execute_commandP3THD + 13712
0x8225381 _Z11mysql_parseP3THDPKcjPS2_ + 339
0x821a9cd _Z16dispatch_command19enum_server_commandP3THDPcj + 2325
0x821a0ac _Z10do_commandP3THD + 612
0x8218c13 handle_one_connection + 253
0x40250aa7 _end + 933387671
0x401e6c2e _end + 932953886
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/refman/5.1/en/resolve-stack-dump.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 0x8e88148 = load data local infile 'e:/wrk/code/combination/dump.txt' replace into table tbl_18 (@h) set a=UNHEX(@h)
thd->thread_id=2
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:
drop table if exists tbl_18;
create table tbl_18 (a varchar(2) character set latin2 collate latin2_czech_cs,primary key(a))engine=falcon;
load data local infile '/tmp/dump.txt' replace into table tbl_18 (@h) set a=UNHEX(@h);

Suggested fix:
.

dump.txt used in the testcase.

Attachment: dump.txt (text/plain), 63.15 KiB.

engine=myisam also crashed:

0x820fa3b handle_segfault + 541
0x859de2c my_strnncollsp_czech + 145
0x858c0cf mi_compare_text + 79
0x858c577 ha_key_cmp + 965
0x85385a4 _mi_seq_search + 426
0x85480e6 w_search + 401
0x85484dc w_search + 1415
0x8547d49 _mi_ck_real_write_btree + 170
0x8547c1e _mi_ck_write_btree + 173
0x8547b64 _mi_ck_write + 215
0x85475cc mi_write + 1020
0x852e72d _ZN9ha_myisam9write_rowEPh + 99
0x82fd975 _ZN7handler12ha_write_rowEPh + 33
0x828e3f0 _Z12write_recordP3THDP8st_tableP12st_copy_info + 1712
0x831e7a9 _Z14read_sep_fieldP3THDR12st_copy_infoP13st_table_listR4ListI4ItemES8_S8_R9READ_INFOR6Stringmb + 1269
0x831d8aa _Z10mysql_loadP3THDP12sql_exchangeP13st_table_listR4ListI4ItemES8_S8_15enum_duplicatesbb + 3658
0x821f478 _Z21mysql_execute_commandP3THD + 13712
0x8225381 _Z11mysql_parseP3THDPKcjPS2_ + 339
0x821a9cd _Z16dispatch_command19enum_server_commandP3THDPcj + 2325
0x821a0ac _Z10do_commandP3THD + 612
0x8218c13 handle_one_connection + 253

engine=innodb also crashed.  (pasting stack traces in order to make searches easier later)

0x820fa3b handle_segfault + 541
0x859deca my_strnncollsp_czech + 303
0x84613dc innobase_mysql_cmp + 274
0x848f208 cmp_whole_field + 577
0x848f53a cmp_dtuple_rec_with_match + 357
0x8483983 page_cur_search_with_match + 1283
0x84d3451 btr_cur_search_to_nth_level + 2272
0x84950a1 row_ins_index_entry_low + 246
0x849567d row_ins_index_entry + 98
0x84957c3 row_ins_index_entry_step + 76
0x84959b1 row_ins + 488
0x8495b1c row_ins_step + 310
0x84974df row_insert_for_mysql + 466
0x8461fad _ZN11ha_innobase9write_rowEPh + 923
0x82fd975 _ZN7handler12ha_write_rowEPh + 33
0x828e3f0 _Z12write_recordP3THDP8st_tableP12st_copy_info + 1712
0x831e7a9 _Z14read_sep_fieldP3THDR12st_copy_infoP13st_table_listR4ListI4ItemES8_S8_R9READ_INFOR6Stringmb + 1269
0x831d8aa _Z10mysql_loadP3THDP12sql_exchangeP13st_table_listR4ListI4ItemES8_S8_15enum_duplicatesbb + 3658
0x821f478 _Z21mysql_execute_commandP3THD + 13712
0x8225381 _Z11mysql_parseP3THDPKcjPS2_ + 339
0x821a9cd _Z16dispatch_command19enum_server_commandP3THDPcj + 2325
0x821a0ac _Z10do_commandP3THD + 612
0x8218c13 handle_one_connection + 253
0x40250aa7 _end + 933387671
0x401e6c2e _end + 932953886

I used bkf free client to clone the tree:

bkf clone bk://mysql.bkbits.net/mysql-6.0-falcon mysql-6.0-falcon

MyIASM isn't affected.

A simpler test case:

drop table if exists t1;
create table t1 (a varchar(2) character set latin2 collate latin2_czech_cs,primary key(a))engine= innodb;
insert into tbl_18 set a=0x5ff;
insert into tbl_18 set a=0xff;

on the last insert the server would crash.

actually MyISAM was affected by my original testcase. I even pasted a stack trace..

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/31216

ChangeSet@1.2538, 2007-07-20 14:47:36+05:00, bar@mysql.com +4 -0
  Bug#29459 server died handling latin2 collate latin2_czech_cs
  Problem: sizeof() was errouneously used instead array_elements(),
  which made the loop access to wrong memory.
  Fix: changing sizeof() to array_elements().

Ok to push

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/31220

ChangeSet@1.2538, 2007-07-20 16:02:43+05:00, bar@mysql.com +4 -0
  Bug#29459 server died handling latin2 collate latin2_czech_cs
  Problem: sizeof() was errouneously used instead array_elements(),
  which made the loop access to wrong memory.
  Fix: changing sizeof() to array_elements().

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/31221

ChangeSet@1.2538, 2007-07-20 16:06:04+05:00, bar@mysql.com +4 -0
  Bug#29459 server died handling latin2 collate latin2_czech_cs
  Problem: sizeof() was errouneously used instead array_elements(),
  which made the loop access to wrong memory.
  Fix: changing sizeof() to array_elements().

Pushed into 5.2.5

what's up with this bug?  still affects 6.0.3 ...

Pushed into 6.0.4-alpha

Noted in 5.2.5, 6.0.4 changelogs.

Use of the latin2_czech_cs collation caused a server crash.