Elena Stepanova added a comment - 2018-07-23 17:38 Thanks a lot for the report and test case. Reproducible as described on 10.2. 10.2 9827c5e1031ca5ebe #3 <signal handler called> #4 0x0000558a593a46d8 in Item_func_in::cleanup (this=0x7f5ca8035928) at /data/src/10.2/sql/item_cmpfunc.h:1664 #5 0x0000558a5924f8d9 in Item::cleanup_processor (this=0x7f5ca8035928, arg=0x0) at /data/src/10.2/sql/item.cc:658 #6 0x0000558a58f01da6 in Item::cleanup_excluding_const_fields_processor (this=0x7f5ca8035928, arg=0x0) at /data/src/10.2/sql/item.h:1589 #7 0x0000558a58f641ed in Item_func_or_sum::walk (this=0x7f5ca8035928, processor=&virtual table offset 784, walk_subquery=false, arg=0x0) at /data/src/10.2/sql/item.h:4202 #8 0x0000558a58f97b2d in pushdown_cond_for_derived (thd=0x7f5ca8000b00, cond=0x7f5ca80136b8, derived=0x7f5ca8012900) at /data/src/10.2/sql/sql_derived.cc:1301 #9 0x0000558a59007ff0 in JOIN::optimize_inner (this=0x7f5ca80175d8) at /data/src/10.2/sql/sql_select.cc:1383 #10 0x0000558a5900715b in JOIN::optimize (this=0x7f5ca80175d8) at /data/src/10.2/sql/sql_select.cc:1115 #11 0x0000558a590103ea in mysql_select (thd=0x7f5ca8000b00, tables=0x7f5ca8012900, wild_num=0, fields=..., conds=0x7f5ca80136b8, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f5ca80175b8, unit=0x7f5ca80046d8, select_lex=0x7f5ca8004e10) at /data/src/10.2/sql/sql_select.cc:3776 #12 0x0000558a5900490f in handle_select (thd=0x7f5ca8000b00, lex=0x7f5ca8004610, result=0x7f5ca80175b8, setup_tables_done_option=0) at /data/src/10.2/sql/sql_select.cc:376 #13 0x0000558a58fd0101 in execute_sqlcom_select (thd=0x7f5ca8000b00, all_tables=0x7f5ca8012900) at /data/src/10.2/sql/sql_parse.cc:6474 #14 0x0000558a58fc6140 in mysql_execute_command (thd=0x7f5ca8000b00) at /data/src/10.2/sql/sql_parse.cc:3481 #15 0x0000558a58fd3ec1 in mysql_parse (thd=0x7f5ca8000b00, rawbuf=0x7f5ca8012478 "select id,val1,val2 from view_bug10_2_16\nwhere ( (val1,val2) in ((1,-1),(2,2)))", length=79, parser_state=0x7f5d0406a200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7995 #16 0x0000558a58fc19e6 in dispatch_command (command=COM_QUERY, thd=0x7f5ca8000b00, packet=0x7f5ca8075a41 "select id,val1,val2 from view_bug10_2_16\nwhere ( (val1,val2) in ((1,-1),(2,2)))", packet_length=79, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1821 #17 0x0000558a58fc0349 in do_command (thd=0x7f5ca8000b00) at /data/src/10.2/sql/sql_parse.cc:1375 #18 0x0000558a5911160a in do_handle_one_connection (connect=0x558a5c393c20) at /data/src/10.2/sql/sql_connect.cc:1335 #19 0x0000558a59111397 in handle_one_connection (arg=0x558a5c393c20) at /data/src/10.2/sql/sql_connect.cc:1241 #20 0x0000558a59533690 in pfs_spawn_thread (arg=0x558a5c36e720) at /data/src/10.2/storage/perfschema/pfs.cc:1862 #21 0x00007f5d0beb0494 in start_thread (arg=0x7f5d0406b700) at pthread_create.c:333 #22 0x00007f5d0a29693f in clone () from /lib/x86_64-linux-gnu/libc.so.6 The problem appeared in 10.2 tree with this commit: commit 6c0f3dd3414a97266912651fb169f630a36f2659 Author: Galina Shalygina Date: Sat May 12 20:32:16 2018 +0200   MDEV-16090: Server crash in in Item_func_in::val_int or assertion `in_item' failure upon SELECT with impossible condition The problem appears because of a wrong implementation of the Item_func_in::build_clone() method. It didn't clone 'array' and 'cmp_fields' fields for the cloned IN predicate and this could cause crashes. The Item_func_in::fix_length_and_dec() method was refactored and a new method named Item_func_in::create_array() was created. It allowed to create 'array' for cloned IN predicates in a proper way.

Galina Shalygina (Inactive) added a comment - 2018-08-01 14:54 - edited The bug appears in the cleanup process in the pushdown into the materialized view/derived table. The query above uses view that is defined with two SELECT statements. "((val1,val2) in ((1,-1),(2,2)))" can be pushed into the view. It can be pushed into both SELECT statements. It is successfully pushed into the first SELECT and the server crashes while processing the second SELECT pushdown. For each SELECT that defines derived table for the condition that can be pushed a clone is created. When first SELECT is processed the cleanup() method calls 'delete array' for the Item_func_in element. It empties 'comparators' array in the 'array' structure. The condition that can be pushed into the second SELECT has the same 'array' link. When cleanup() is called for this condition it tries to reach already lame 'array' and that causes a crash. So after the first cleanup() call this link becomes lame. The bug occurs because of the wrong build_clone() method work for the Item_func_in items. To build the 'array' field for the clone Item_func_in::create_array() method is called there. It can be seen that for the case when the result type of the Item_func_in item is ROW_RESULT no 'array' is initialized in the create_array() method. It is implied that 'array' was created before the call of the create_array() method. It can be seen that the only method where create_array() call occurs is Item_func_in::fix_length_and_dec(). In this method 'array' is created for the case when the result type is ROW_RESULT before the create_array() call. Also there 'cmp_items' array is filled with appropriate values. In Item_func_in::build_clone() method this array is filled with 0. Therefore it was also a mistake and in some cases that can cause a bug. To make build_clone() method work right create_array() call should be changed on fix_length_and_dec() call.

Igor Babaev (Inactive) added a comment - 2018-08-03 19:20 Ok to push

Galina Shalygina (Inactive) added a comment - 2018-08-27 16:11 Pushed in 10.2