Bug #34590 | Innodb crash in build_template() on multi-table delete | ||
---|---|---|---|
Submitted: | 15 Feb 2008 11:51 | Modified: | 20 Jan 2010 11:45 |
Reporter: | Philip Stoev | Email Updates: | |
Status: | Duplicate | Impact on me: | |
Category: | MySQL Server: Optimizer | Severity: | S3 (Non-critical) |
Version: | 6.0.4 | OS: | Any |
Assigned to: | Assigned Account | CPU Architecture: | Any |
Tags: | index_condition_pushdown, optimizer_switch, v6 |
[15 Feb 2008 11:51]
Philip Stoev
[15 Feb 2008 12:04]
Philip Stoev
May be related to bug #34591 - same queries are involved, stack trace is different.
[15 Feb 2008 12:57]
Susanne Ebrecht
Verified as described. mysql> INSERT INTO view2 (t1_uuid, t2_date) VALUES (@uuid, '2009-09-09'); Query OK, 1 row affected (0.00 sec) mysql> CALL delete_multi(@uuid); ERROR 2013 (HY000): Lost connection to MySQL server during query mysql> select version()\G *************************** 1. row *************************** version(): 6.0.5-alpha-debug
[19 Feb 2008 18:02]
Valeriy Kravchuk
We should check if 5.x versions are also affected.
[19 Feb 2008 18:56]
Valeriy Kravchuk
This bug is NOT repeatable with 5.0.54.
[19 Feb 2008 19:03]
Valeriy Kravchuk
The bug is not repeatable with 5.1.23-rc also. So, this is indeed a 6.0.x-only bug.
[4 Mar 2008 17:34]
Heikki Tuuri
Calvin, when you build 6.0, please look at this crash. MySQL may be calling handler functions in a wrong order. --Heikki
[2 Jul 2008 14:38]
Philip Stoev
This crash just happened on a single-table DELETE: DELETE K FROM `B` AS K WHERE K . int_key < 118 int_key is an integer column with a key on it. stack trace is : #0 0x00110416 in __kernel_vsyscall () #1 0x00581c78 in pthread_kill () from /lib/libpthread.so.0 #2 0x085b0dc4 in my_write_core (sig=11) at stacktrace.c:307 #3 0x08213e88 in handle_segfault (sig=11) at mysqld.cc:2638 #4 <signal handler called> #5 0x084cbaa7 in build_template (prebuilt=0xadbdb068, thd=<value optimized out>, table=0x9fadf70, file=0x9fa3320, templ_type=0) at handler/ha_innodb.cc:3265 #6 0x084cc543 in ha_innobase::index_read (this=0x9fa3320, buf=0x9fa34b8 "Ъ", key_ptr=0x9f9df28 "\001", key_len=5, find_flag=HA_READ_AFTER_KEY) at handler/ha_innodb.cc:4203 #7 0x0830bd93 in handler::index_read_map (this=0x9fa3320, buf=0x9fa34b8 "Ъ", key=0x9f9df28 "\001", keypart_map=1, find_flag=HA_READ_AFTER_KEY) at ../../sql/handler.h:1664 #8 0x0830436f in handler::read_range_first (this=0x9fa3320, start_key=0x9fa33a8, end_key=0x9fa33b8, eq_range_arg=false, sorted=false) at handler.cc:4907 #9 0x084c7fdf in ha_innobase::read_range_first (this=0x9fa3320, start_key=0x9fa33a8, end_key=0x9fa33b8, eq_range_arg=<value optimized out>, sorted=<value optimized out>) at handler/ha_innodb.cc:8394 #10 0x0830337d in handler::multi_range_read_next (this=0x9fa3320, range_info=0xa896b58c) at handler.cc:4262 #11 0x08304d40 in DsMrr_impl::dsmrr_next (this=0x9fa3494, h=0x9fa3320, range_info=0xa896b58c) at handler.cc:4464 #12 0x084c80af in ha_innobase::multi_range_read_next (this=0x9fa3320, range_info=0xa896b58c) at handler/ha_innodb.cc:8327 #13 0x082ea15a in QUICK_RANGE_SELECT::get_next (this=0x9fc8030) at opt_range.cc:8518 #14 0x082fe857 in rr_quick (info=0x9f940cc) at records.cc:298 #15 0x0826e88c in join_init_read_record (tab=0x9f94088) at sql_select.cc:14481 #16 0x08281615 in sub_select (join=0x9fc4ca8, join_tab=0x9f94088, end_of_records=false) at sql_select.cc:13636 #17 0x0828b5b9 in do_select (join=0x9fc4ca8, fields=0x9fb404c, table=0x0, procedure=0x0) at sql_select.cc:13387 #18 0x0828d761 in JOIN::exec (this=0x9fc4ca8) at sql_select.cc:2811 #19 0x0828e1fa in mysql_select (thd=0x9fb2bd8, rref_pointer_array=0x9fb40bc, tables=0x9f93570, wild_num=0, fields=@0x9fb404c, conds=0x9f93ab8, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=3489942144, result=0x9f93c08, unit=0x9fb3d28, select_lex=0x9fb3fb8) at sql_select.cc:3001 #20 0x0822350f in mysql_execute_command (thd=0x9fb2bd8) at sql_parse.cc:3127 #21 0x0822a02e in mysql_parse (thd=0x9fb2bd8, inBuf=0x9f92e08 "DELETE K FROM `B` AS K WHERE K . int_key < 118", length=46, found_semicolon=0xa896c314) at sql_parse.cc:5811 #22 0x0822a921 in dispatch_command (command=COM_QUERY, thd=0x9fb2bd8, packet=0x9fa3711 "DELETE K FROM `B` AS K WHERE K . int_key < 118 ", packet_length=48) at sql_parse.cc:1051 #23 0x0822ba49 in do_command (thd=0x9fb2bd8) at sql_parse.cc:724 #24 0x0821bef0 in handle_one_connection (arg=0x9fb2bd8) at sql_connect.cc:1153 #25 0x0057d32f in start_thread () from /lib/libpthread.so.0 #26 0x0049a27e in clone () from /lib/libc.so.6 The crash is here: 3260 templ->mysql_length_bytes = (ulint) 3261 (((Field_varstring*)field)->length_bytes); 3262 } 3263 3264 templ->charset = dtype_get_charset_coll_noninline( 3265 index->table->cols[i].prtype); <<<< HERE 3266 templ->mbminlen = index->table->cols[i].mbminlen; 3267 templ->mbmaxlen = index->table->cols[i].mbmaxlen; 3268 templ->is_unsigned = index->table->cols[i].prtype 3269 & DATA_UNSIGNED; (gdb) print index $1 = (dict_index_t *) 0xadd3ba68 (gdb) print index->table $2 = (dict_table_t *) 0xadd35068 (gdb) print index->table->cols $3 = (dict_col_t *) 0x6
[8 Jul 2008 18:55]
Sergey Petrunya
The crash doesn't occur on 6.0 if I turn off DS-MRR and Index Condition Pushdown using set optimizer_use_mrr='disable'; set engine_condition_pushdown=off;
[8 Jul 2008 18:57]
Sergey Petrunya
... which means the problem is on MySQL side, not on InnoDB's. Changing category and re-assigning accordingly.
[21 Aug 2008 22:23]
Sergey Petrunya
* Repeatable on the latest bzr tree * Repeatable when fix for BUG#37842 is applied * Not repeatable if one does SET engine_condition_pushdown=off * The testcase does not use DS-MRR. This seems to be an index-condition-pushdown problem.
[26 Aug 2008 9:44]
Sergey Petrunya
After initial investigation it seems that the problem is that build_template() doesn't work correctly when IndexConditionPushdown is used lock_type==LOCK_X which causes template_type=ROW_MYSQL_WHOLE_ROW. The part of ICP code inside row_search_for_mysql() expects that the first columns in the template are the index components. When that isn't the case (and the columns are of different length), it unpacks index tuple to wrong location, causing memory overrun and all kinds of funny effects.
[8 Jul 2009 6:04]
Nidhi Shrotriya
Marking as duplicate of 45029.
[8 Jul 2009 6:06]
Nidhi Shrotriya
Closing it as duplicate of 45029.
[4 Dec 2009 7:16]
Sveta Smirnova
Not repeatable for me with latest 6.0-codebase.
[9 Dec 2009 10:09]
Olav Sandstå
Support for ICP in InnoDB has been disabled (see Bug#45029). In order to enable it this requires adding back the HA_DO_INDEX_COND_PUSHDOWN flag in index_flags() in storage/innobase/handler/ha_innodb.h. Setting it back to verified.
[20 Jan 2010 11:43]
Olav Sandstå
The crash reported in this bug is the same as several other bug reports caused by Index Condition Pushdown for InnoDB. These bugs are fixed by the fixes committed for Bug#43360 and Bug#36981. I have verified that the initial test case in this bug report still creates the crash if the fix is not applied but runs correctly after applying the patches. The test case is almost identical to the test case committed for Bug#35080 so I will not add this as a separate test case. Closing this bug as duplicate of Bug#43360 and Bug#36981.