| Bug #54311 | Crash on CHECK PARTITION after concurrent LOAD DATA and adaptive_hash_index=OFF | ||
|---|---|---|---|
| Submitted: | 7 Jun 2010 21:27 | Modified: | 14 Oct 2010 15:42 |
| Reporter: | Elena Stepanova | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: InnoDB Plugin storage engine | Severity: | S2 (Serious) |
| Version: | 5.1.47, 5.5.3, 5.5.4, 5.5.5-m3, 5.6.99 | OS: | Any |
| Assigned to: | Jimmy Yang | CPU Architecture: | Any |
[7 Jun 2010 21:28]
Elena Stepanova
Load file for the test case
Attachment: test.load (application/octet-stream, text), 288.21 KiB.
[10 Jun 2010 18:26]
Mikhail Izioumtchenko
I don't think it has anything to do with partitions or load data. Rather, CHECK TABLE calls btr_search_validate(). BTW I'm not sure it really really must. In any case btr_search_validate() code seems to be oblivious to the of a.h.i. being turned off while we are validating, based on a cursory look. Assigning to Marko because it is only recently he implemented dynamic innodb-a.h.i. variable.
[10 Jun 2010 18:53]
Elena Stepanova
It might well be that there is a different test case which does not use partitions and still reveals the same problem. In this one, however, I could not just remove partitioning from the table and replace ALTER .. CHECK PARTITION by simple CHECK TABLE -- the crash would not happen. In regard to LOAD DATA, it could also be that it is not necessary and is specific for this test case. I could not get rid of the two LOAD DATA in the middle of the test, in connections con88 and con89 -- the crash stopped happening. I also tried to replace it with some other DML, but did not succeed -- maybe just because LOAD here is a relatively long operation, or due to lack of luck. The first and the last LOAD, in init and in con91, are not strictly required, but they seemed to increase the probability of the failure somehow, so I left them in the test (although it could be just statistical error).
[10 Jun 2010 19:16]
Mikhail Izioumtchenko
to trigger this bug we need to do something for the a.h.i. to appear and be big enough, then change the a.h.i. settings at the right moment so no wonder we need some activity in the test case. The code instrumentation that could help trigger the bug could be: - release btr_search_latch for more time in btr_search_validate - make a.h.i. build mandatory for each new page, somehow there may be (unlikely) more bugs like this, related to acquiring btr_search_latch then not checking btr_search_enabled flag.
[21 Jun 2010 3:56]
Jimmy Yang
Also saw following stack, seems the check partition is not necessary, but block->index is null in btr_search_validate():
warning: Can't read pathname for load map: Input/output error.
Core was generated by `/home/jy/work/mysql5.1_2/mysql-5.1/sql/mysqld --defaults-group-suffix=.1 --defa'.
Program terminated with signal 6, Aborted.
#0 0x00557422 in __kernel_vsyscall ()
#0 0x00557422 in __kernel_vsyscall ()
#1 0x00264e93 in __pthread_kill (threadid=2808716144, signo=6)
at ../nptl/sysdeps/unix/sysv/linux/pthread_kill.c:64
#2 0x085ddc89 in my_write_core (sig=6) at stacktrace.c:329
#3 0x0821d863 in handle_segfault (sig=6) at mysqld.cc:2571
#4 <signal handler called>
#5 0x00557422 in __kernel_vsyscall ()
#6 0x006d04d1 in *__GI_raise (sig=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#7 0x006d3932 in *__GI_abort () at abort.c:92
#8 0x0852290b in dict_index_is_ibuf (index=0x0) at ./include/dict0dict.ic:240
#9 0x085018b7 in btr_search_validate () at btr/btr0sea.c:1805
#10 0x0850024d in btr_search_drop_page_hash_index (block=0xaec53094)
at btr/btr0sea.c:1155
#11 0x085077fe in buf_pool_drop_hash_index () at buf/buf0buf.c:1103
#12 0x084fe8fd in btr_search_disable () at btr/btr0sea.c:207
#13 0x08459cb8 in innodb_adaptive_hash_index_update (thd=0xa5798c8,
var=0x875d9b8, var_ptr=0x875ea0c, save=0xa58afd8)
at handler/ha_innodb.cc:10320
#14 0x08429cb0 in sys_var_pluginvar::update (this=0x9d24f78, thd=0xa5798c8,
var=0xa58afc8) at sql_plugin.cc:2782
#15 0x0824468d in set_var::update (this=0xa58afc8, thd=0xa5798c8)
at set_var.cc:3606
#16 0x0824419c in sql_set_variables (thd=0xa5798c8, var_list=0xa57af40)
at set_var.cc:3481
#17 0x082325e7 in mysql_execute_command (thd=0xa5798c8) at sql_parse.cc:3478
#18 0x0823a166 in mysql_parse (thd=0xa5798c8,
inBuf=0xa58ae70 "SET GLOBAL innodb_adaptive_hash_index = OFF", length=43,
found_semicolon=0xa7699058) at sql_parse.cc:5971
#19 0x0822c117 in dispatch_command (command=COM_QUERY, thd=0xa5798c8,
packet=0xa582e11 "SET GLOBAL innodb_adaptive_hash_index = OFF",
packet_length=43) at sql_parse.cc:1233
#20 0x0822b20b in do_command (thd=0xa5798c8) at sql_parse.cc:874
#21 0x082295b2 in handle_one_connection (arg=0xa5798c8) at sql_connect.cc:1127
#22 0x0025f80e in start_thread (arg=0xa7699b70) at pthread_create.c:300
#23 0x007728de in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
#7 0x0028c932 in *__GI_abort () at abort.c:92
#8 0x0852290b in dict_index_is_ibuf (index=0x0) at ./include/dict0dict.ic:240
#9 0x085018b7 in btr_search_validate () at btr/btr0sea.c:1805
#10 0x0850024d in btr_search_drop_page_hash_index (block=0xaec69f50)
at btr/btr0sea.c:1155
#11 0x084ed125 in btr_page_reorganize_low (recovery=0, block=0xaec69f50,
index=0xaa2ae38, mtr=0xa76db2e0) at btr/btr0btr.c:994
#12 0x084ed4f8 in btr_page_reorganize (block=0xaec69f50, index=0xaa2ae38,
mtr=0xa76db2e0) at btr/btr0btr.c:1109
#13 0x084ef369 in btr_page_split_and_insert (cursor=0xa76db274,
tuple=0xaa2f6a0, n_ext=0, mtr=0xa76db2e0) at btr/btr0btr.c:2151
#14 0x084f5734 in btr_cur_pessimistic_insert (flags=0, cursor=0xa76db274,
entry=0xaa2f6a0, rec=0xa76db2d4, big_rec=0xa76db2c4, n_ext=0,
thr=0xaa2c9a0, mtr=0xa76db2e0) at btr/btr0cur.c:1418
#15 0x084ab41d in row_ins_index_entry_low (mode=33, index=0xaa2ae38,
entry=0xaa2f6a0, n_ext=0, thr=0xaa2c9a0) at row/row0ins.c:2093
#16 0x084ab692 in row_ins_index_entry (index=0xaa2ae38, entry=0xaa2f6a0,
n_ext=0, foreign=1, thr=0xaa2c9a0) at row/row0ins.c:2171
#17 0x084ab980 in row_ins_index_entry_step (node=0xaa2f488, thr=0xaa2c9a0)
at row/row0ins.c:2247
#18 0x084abbe3 in row_ins (node=0xaa2f488, thr=0xaa2c9a0) at row/row0ins.c:2379
#19 0x084abe4e in row_ins_step (thr=0xaa2c9a0) at row/row0ins.c:2489
#20 0x084b2e9c in row_insert_for_mysql (mysql_rec=0xaa42778 "\376GN",
prebuilt=0xaa2f038) at row/row0mysql.c:1137
#21 0x0844fb2b in ha_innobase::write_row (this=0xaa42628,
record=0xaa42778 "\376GN") at handler/ha_innodb.cc:4707
#22 0x08362cf5 in handler::ha_write_row (this=0xaa42628,
buf=0xaa42778 "\376GN") at handler.cc:4650
#23 0x0836be15 in ha_partition::write_row (this=0xa9f2400,
buf=0xaa42778 "\376GN") at ha_partition.cc:3080
#24 0x08362cf5 in handler::ha_write_row (this=0xa9f2400,
buf=0xaa42778 "\376GN") at handler.cc:4650
#25 0x082c30f4 in write_record (thd=0xaa5ae00, table=0xaa2a2e8,
info=0xa76dbc40) at sql_insert.cc:1606
#26 0x083961f6 in read_sep_field (thd=0xaa5ae00, info=...,
table_list=0xaa6a128, fields_vars=..., set_fields=..., set_values=...,
read_info=..., enclosed=..., skip_lines=0, ignore_check_option_errors=true)
at sql_load.cc:1009
#27 0x083947c4 in mysql_load (thd=0xaa5ae00, ex=0xaa6a0a8,
table_list=0xaa6a128, fields_vars=..., set_fields=..., set_values=...,
handle_duplicates=DUP_ERROR, ignore=true, read_file_from_client=true)
at sql_load.cc:439
#28 0x082324c4 in mysql_execute_command (thd=0xaa5ae00) at sql_parse.cc:3459
#29 0x0823a166 in mysql_parse (thd=0xaa5ae00,
inBuf=0xaa69f88 "LOAD DATA LOCAL INFILE 'test.load'\n \t\tINTO TABLE t_celosia_ddl_partitions (user_num, name)", length=90, found_semicolon=0xa76dd058)
at sql_parse.cc:5971
#30 0x0822c117 in dispatch_command (command=COM_QUERY, thd=0xaa5ae00,
packet=0xaa61f29 "833776188\tZhwgccgsmcjde Tpnxxuzljhm\n6719522349\tVdvavzgwikzin Ylzjo Rvin\n7576420800\tPqjncfpryzrz Bfpgdgssa\n5058396157\tKryrdzofafa Ayroaa Freatxevntc\n2883502881\tWskwvko\n8234179977\tAgsnpi\n9468634778\tCre "..., packet_length=90) at sql_parse.cc:1233
#31 0x0822b20b in do_command (thd=0xaa5ae00) at sql_parse.cc:874
#32 0x082295b2 in handle_one_connection (arg=0xaa5ae00) at sql_connect.cc:1127
#33 0x0090480e in start_thread (arg=0xa76ddb70) at pthread_create.c:300
#34 0x0032b8de in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
[21 Jun 2010 5:04]
Jimmy Yang
Above error was triggered only when "UNIV_DEBUG" is defined, please note block->index is set to NULL in btr_search_drop_page_hash_index() right before btr_search_validate() is called. Apparently, this is also a bug needs to be fixed. Need to further investigate if this is related to reported bug.
[21 Jun 2010 13:05]
Marko Mäkelä
The function buf_pool_drop_hash_index() is releasing and reacquiring btr_search_latch, so that it can x-latch block->lock in between. A possible fix is that all code paths that are acquiring btr_search_latch should also check btr_search_enabled and do nothing to/with the adaptive hash index if btr_search_enabled==FALSE.
[21 Jun 2010 13:42]
Marko Mäkelä
I reviewed all acquisitions of btr_search_latch in the code. The only bug I found is in btr_search_validate(): it fails to ensure btr_search_enabled==TRUE after acquiring btr_search_latch, before accessing any adaptive hash index fields. Note that btr_search_disable() makes block->is_hashed=FALSE to all blocks. Therefore, in some places is enough to check block->is_hashed instead of btr_search_enabled. See also Bug #50461.
[22 Jun 2010 12:45]
Jimmy Yang
The problem seems due to page split when btr_search_enabled is disabled.
When we do page split, half of the page rows move to a new page. And for those moved rows, their entry will be updated when we build hash index on the new page in btr_search_build_page_hash_index(). Since we turn off the btr_search_enabled bit, btr_search_build_page_hash_index stopped update the entry. The net result is that we have more hash entry for the old page than it really have.
Stack:
#0 ha_insert_for_fold_func (table=0xad42728, fold=1111565036,
block=0xaebd52dc, data=0xaf20807e) at ha/ha0ha.c:172
#1 0x084fabc2 in btr_search_build_page_hash_index (index=0xadb6c80,
block=0xaebd52dc, n_fields=2, n_bytes=0, left_side=0) at btr/btr0sea.c:1410
#2 0x084faeac in btr_search_move_or_delete_hash_entries (
new_block=0xaebd52dc, block=0xaebd51b8, index=0xadb6c80)
at btr/btr0sea.c:1478
#3 0x0848b385 in page_copy_rec_list_end (new_block=0xaebd52dc,
block=0xaebd51b8, rec=0xaf205f81 "Lawfw\200", index=0xadb6c80,
mtr=0xa764a2e0) at page/page0page.c:711
#4 0x0848c287 in page_move_rec_list_end (new_block=0xaebd52dc,
block=0xaebd51b8, split_rec=0xaf205f81 "Lawfw\200", index=0xadb6c80,
mtr=0xa764a2e0) at page/page0page.c:1205
#5 0x084e9645 in btr_page_split_and_insert (cursor=0xa764a274,
tuple=0xadbb4e8, n_ext=0, mtr=0xa764a2e0) at btr/btr0btr.c:2064
#6 0x084ef9f1 in btr_cur_pessimistic_insert (flags=0, cursor=0xa764a274,
entry=0xadbb4e8, rec=0xa764a2d4, big_rec=0xa764a2c4, n_ext=0,
thr=0xadb87e8, mtr=0xa764a2e0) at btr/btr0cur.c:1418
#7 0x084a7435 in row_ins_index_entry_low (mode=33, index=0xadb6c80,
entry=0xadbb4e8, n_ext=0, thr=0xadb87e8) at row/row0ins.c:2093
gdb) p block->page->offset
$188 = 254
(gdb) p prev_node->block->page->offset
$189 = 253
when we later get to btr_search_drop_page_hash_index(), we will have more entries for the page than "n_cached" entry we would delete, however, it sets block->index = NULL. And in btr_search_validate(), it would find entry with the same block, it would trigger sig 11 when it tries to access block->index,
[23 Jun 2010 9:25]
Jimmy Yang
A fix is to continue to allow updates on the existing entries when we start the disabling process, but not to add new nodes. And completely block all updates only after the hash index disable process completes.
[1 Jul 2010 4:53]
Bugs System
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/112636 3132 Jimmy Yang 2010-06-30 Fix bug #54311 Crash on CHECK PARTITION after concurrent LOAD DATA and adaptive_hash_index=OFF rb://389 approved by Marko
[1 Jul 2010 5:07]
Bugs System
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/112638 3535 Jimmy Yang 2010-06-30 Port fix for bug #54311 from mysql-trunk-innodb to mysql-5.1-innodb codeline. Bug #54311: Crash on CHECK PARTITION after concurrent LOAD DATA and adaptive_hash_index=OFF
[4 Aug 2010 7:49]
Bugs System
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100731131027-1n61gseejyxsqk5d) (version source revid:alik@sun.com-20100731074942-o840woifuqioxxe4) (merge vers: 5.5.6-m3) (pib:18)
[4 Aug 2010 7:55]
Bugs System
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100731131027-1n61gseejyxsqk5d) (version source revid:alik@sun.com-20100731074942-o840woifuqioxxe4) (merge vers: 5.5.6-m3) (pib:18)
[4 Aug 2010 7:56]
Bugs System
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100731131027-1n61gseejyxsqk5d) (version source revid:alik@sun.com-20100731074942-o840woifuqioxxe4) (merge vers: 5.5.6-m3) (pib:18)
[4 Aug 2010 7:57]
Bugs System
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100731131027-1n61gseejyxsqk5d) (version source revid:alik@sun.com-20100731074942-o840woifuqioxxe4) (merge vers: 5.5.6-m3) (pib:18)
[4 Aug 2010 7:58]
Bugs System
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100731131027-1n61gseejyxsqk5d) (version source revid:alik@sun.com-20100731074942-o840woifuqioxxe4) (merge vers: 5.5.6-m3) (pib:18)
[4 Aug 2010 7:59]
Bugs System
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100731131027-1n61gseejyxsqk5d) (version source revid:alik@sun.com-20100731074942-o840woifuqioxxe4) (merge vers: 5.5.6-m3) (pib:18)
[4 Aug 2010 8:00]
Bugs System
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100731131027-1n61gseejyxsqk5d) (version source revid:alik@sun.com-20100731074942-o840woifuqioxxe4) (merge vers: 5.5.6-m3) (pib:18)
[4 Aug 2010 8:07]
Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 8:13]
Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 8:14]
Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 8:15]
Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 8:16]
Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 8:17]
Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 8:23]
Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804081533-c1d3rbipo9e8rt1s) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 9:00]
Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804081533-c1d3rbipo9e8rt1s) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:20)
[4 Aug 2010 9:03]
Bugs System
Pushed into mysql-next-mr (revid:alik@ibmvm-20100804081630-ntapn8bf9pko9vj3) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (pib:20)
[19 Aug 2010 15:39]
Bugs System
Pushed into mysql-5.1 5.1.51 (revid:build@mysql.com-20100819151858-muaaor6jojb5ouzj) (version source revid:build@mysql.com-20100819151858-muaaor6jojb5ouzj) (merge vers: 5.1.51) (pib:20)
[14 Oct 2010 8:32]
Bugs System
Pushed into mysql-5.1-telco-7.0 5.1.51-ndb-7.0.20 (revid:martin.skold@mysql.com-20101014082627-jrmy9xbfbtrebw3c) (version source revid:martin.skold@mysql.com-20101014082627-jrmy9xbfbtrebw3c) (merge vers: 5.1.51-ndb-7.0.20) (pib:21)
[14 Oct 2010 8:47]
Bugs System
Pushed into mysql-5.1-telco-6.3 5.1.51-ndb-6.3.39 (revid:martin.skold@mysql.com-20101014083757-5qo48b86d69zjvzj) (version source revid:martin.skold@mysql.com-20101014083757-5qo48b86d69zjvzj) (merge vers: 5.1.51-ndb-6.3.39) (pib:21)
[14 Oct 2010 9:02]
Bugs System
Pushed into mysql-5.1-telco-6.2 5.1.51-ndb-6.2.19 (revid:martin.skold@mysql.com-20101014084420-y54ecj85j5we27oa) (version source revid:martin.skold@mysql.com-20101014084420-y54ecj85j5we27oa) (merge vers: 5.1.51-ndb-6.2.19) (pib:21)
[14 Oct 2010 15:42]
Jon Stephens
Setting back to Closed; see above.
Description: #3 0x000000000080ff8b in btr_search_validate () at storage/innobase/include/dict0dict.ic:239 #4 0x00000000007bfd03 in row_check_table_for_mysql (prebuilt=0x14917f0) at storage/innobase/row/row0mysql.c:4170 #5 0x00000000007ad19f in ha_innobase::check (this=0x1485c40, thd=<value optimized out>, check_opt=<value optimized out>) at storage/innobase/handler/ha_innodb.cc:7371 #6 0x000000000068b9fa in handler::ha_check (this=0x1485c40, thd=0x14d4230, check_opt=0x14d6778) at sql/handler.cc:3122 #7 0x0000000000680b30 in handle_opt_part (thd=0x0, check_opt=0x2aaaae6bfa00, file=0x15, flag=0) at sql/ha_partition.cc:1012 #8 0x0000000000680f33 in ha_partition::handle_opt_partitions (this=0x14913a0, thd=0x14d4230, check_opt=0x14d6778, flag=3) at sql/ha_partition.cc:1169 #9 0x000000000068b9fa in handler::ha_check (this=0x14913a0, thd=0x14d4230, check_opt=0x14d6778) at sql/handler.cc:3122 #10 0x00000000005deb1e in mysql_admin_table (thd=0x14d4230, tables=0x14d1d00, check_opt=0x14d6778, operator_name=0xa1efb1 "check", lock_type=TL_READ_NO_INSERT, open_for_modify=false, no_warnings_for_error=false, extra_open_options=32, prepare_func=0, operator_func= (int ( class handler::*)(class THD *,HA_CHECK_OPT *,)) 857908, view_operator_func=0x5f16c0 <view_checksum(THD*, TABLE_LIST*)>) at sql/sql_table.cc:4921 #11 0x00000000005dfbc9 in mysql_check_table (thd=0xfc, tables=0x0, check_opt=0x2aaaae6bfa00) at sql/sql_table.cc:5457 #12 0x000000000057e490 in mysql_execute_command (thd=0x14d4230) at sql/sql_parse.cc:3015 #13 0x0000000000580fed in mysql_parse (thd=0x14d4230, inBuf=0x14d1bb0 "ALTER TABLE t_celosia_ddl_partitions CHECK PARTITION p0", length=<value optimized out>, parser_state=0x4490b7e0) at sql/sql_parse.cc:5816 #14 0x0000000000581cfa in dispatch_command (command=COM_QUERY, thd=0x14d4230, packet=<value optimized out>, packet_length=55) at sql/sql_parse.cc:1134 #15 0x000000000058257d in do_command (thd=0x14d4230) at sql/sql_parse.cc:771 #16 0x00000000006196cb in do_handle_one_connection (thd_arg=0x14d4230) at sql/sql_connect.cc:1195 #17 0x000000000061a1b4 in handle_one_connection (arg=<value optimized out>) at sql/sql_connect.cc:1134 #18 0x00000000008e4dfb in pfs_spawn_thread (arg=<value optimized out>) at storage/perfschema/pfs.cc:1011 #19 0x00002b2bc60e3143 in start_thread () from /lib64/libpthread.so.0 #20 0x00002b2bc67528cd in clone () from /lib64/libc.so.6 #21 0x0000000000000000 in ?? () Version: '5.5.5-m3-log' mysqld got signal 11 ; thd->query at 0x14d1bb0 = ALTER TABLE t_celosia_ddl_partitions CHECK PARTITION p0 thd->thread_id=7 thd->killed=NOT_KILLED The coredump is for InnoDB Plugin 1.0.6, but with 1.1 the crash also happens. How to repeat: # The test case below is not completely deterministic, # but I'm getting reliable number of failures, with it, # about 90% on recent builds # (91 failures in a 100-attempt run, usually 9/10 in 10-attempt runs). # Please run several times if you don't get a crash at once. # Please note that the test requires a load file, it is attached. #--- Test case ---- --source include/have_innodb.inc # Init SET GLOBAL event_scheduler = OFF; let $adaptive_hash_index = `SELECT @@innodb_adaptive_hash_index`; DROP DATABASE IF EXISTS celosia_features; CREATE DATABASE celosia_features; USE celosia_features; DROP TABLE IF EXISTS celosia_features.t_celosia_ddl_partitions; CREATE TABLE celosia_features.t_celosia_ddl_partitions (id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, user_num CHAR(10), name VARCHAR(255) NOT NULL, INDEX names (name(255))) ENGINE = InnoDB PARTITION BY HASH(id) PARTITIONS 4; LOAD DATA LOCAL INFILE 'test.load' INTO TABLE celosia_features.t_celosia_ddl_partitions (user_num, name); # End of init --connect (con88,localhost,root,,celosia_features) SET AUTOCOMMIT = 0; LOAD DATA LOCAL INFILE 'test.load' INTO TABLE t_celosia_ddl_partitions (user_num, name); --disconnect con88 --connect (con89,localhost,root,,celosia_features) SELECT COUNT(*) INTO @table_count FROM t_celosia_ddl_partitions; --send LOAD DATA LOCAL INFILE 'test.load' INTO TABLE t_celosia_ddl_partitions (user_num, name); --connect (con90,localhost,root,,test) --send SET GLOBAL innodb_adaptive_hash_index = OFF; --connection con89 --reap --disconnect con89 --connection con90 --reap --disconnect con90 --connect (con91,localhost,root,,celosia_features) LOAD DATA LOCAL INFILE 'test.load' INTO TABLE t_celosia_ddl_partitions (user_num, name); --disconnect con91 --connect (con92,localhost,root,,celosia_features) ALTER TABLE t_celosia_ddl_partitions CHECK PARTITION p0; # Cleanup, just in case we get here --connection default DROP DATABASE celosia_features; eval SET GLOBAL innodb_adaptive_hash_index = $adaptive_hash_index; --exit #--- End of test case ----