--source include/have_innodb.inc

CREATE TABLE t1 (a INT) ENGINE=InnoDB;

CREATE VIEW v1 AS SELECT * FROM t1;

CREATE TABLE t2 (b INT) ENGINE=InnoDB;

DELETE FROM v1 WHERE a IN ( SELECT a FROM t2 );

#3  <signal handler called>

#4  0x00000000005f6b48 in Bitmap<64u>::merge (this=0x180, map2=...) at /data/src/10.0/sql/sql_bitmap.h:158

#5  0x0000000000689db2 in add_key_field (join=0x7f39733ae198, key_fields=0x7f3989085d68, and_level=0, cond=0x7f39733af450, field=0x7f39730289a8, eq_func=true, value=0x7f39733af4e8, num_values=1, usable_tables=18446744073709551615, sargables=0x7f3989085e40) at /data/src/10.0/sql/sql_select.cc:4410

#6  0x000000000068a25f in add_key_equal_fields (join=0x7f39733ae198, key_fields=0x7f3989085d68, and_level=0, cond=0x7f39733af450, field_item=0x7f39731a5e50, eq_func=true, val=0x7f39733af4e8, num_values=1, usable_tables=18446744073709551615, sargables=0x7f3989085e40) at /data/src/10.0/sql/sql_select.cc:4559

#7  0x000000000068ae0e in add_key_fields (join=0x7f39733ae198, key_fields=0x7f3989085d68, and_level=0x7f3989085d74, cond=0x7f39733af450, usable_tables=18446744073709551615, sargables=0x7f3989085e40) at /data/src/10.0/sql/sql_select.cc:4791

#8  0x000000000068c26a in update_ref_and_keys (thd=0x7f397b757070, keyuse=0x7f3989085e20, join_tab=0x7f39733aeaf8, tables=1, cond=0x7f39733af450, normal_tables=18446744073709551615, select_lex=0x7f39731a4888, sargables=0x7f3989085e40) at /data/src/10.0/sql/sql_select.cc:5262

#9  0x00000000006bb0f4 in JOIN::reoptimize (this=0x7f39733ae198, added_where=0x7f39733af450, join_tables=1, save_to=0x0) at /data/src/10.0/sql/sql_select.cc:24897

#10 0x00000000007b4c5a in JOIN::choose_subquery_plan (this=0x7f39733ae198, join_tables=1) at /data/src/10.0/sql/opt_subselect.cc:5834

#11 0x0000000000689243 in make_join_statistics (join=0x7f39733ae198, tables_list=..., conds=0x0, keyuse_array=0x7f39733ae4c0) at /data/src/10.0/sql/sql_select.cc:4074

#12 0x000000000067fad1 in JOIN::optimize_inner (this=0x7f39733ae198) at /data/src/10.0/sql/sql_select.cc:1345

#13 0x000000000067e9ca in JOIN::optimize (this=0x7f39733ae198) at /data/src/10.0/sql/sql_select.cc:1029

#14 0x000000000063e68e in st_select_lex::optimize_unflattened_subqueries (this=0x7f397b75b0f8, const_only=false) at /data/src/10.0/sql/sql_lex.cc:3553

#15 0x0000000000990bbc in mysql_delete (thd=0x7f397b757070, table_list=0x7f39731a4190, conds=0x7f39733ae840, order_list=0x7f397b75b360, limit=18446744073709551615, options=0, result=0x7f39731a5c58) at /data/src/10.0/sql/sql_delete.cc:292

#16 0x000000000064c1b9 in mysql_execute_command (thd=0x7f397b757070) at /data/src/10.0/sql/sql_parse.cc:3602

#17 0x0000000000653f16 in mysql_parse (thd=0x7f397b757070, rawbuf=0x7f39731a4088 "DELETE FROM v1 WHERE a IN ( SELECT a FROM t2 )", length=46, parser_state=0x7f3989087640) at /data/src/10.0/sql/sql_parse.cc:6569

#18 0x0000000000646a55 in dispatch_command (command=COM_QUERY, thd=0x7f397b757070, packet=0x7f39811dc071 "DELETE FROM v1 WHERE a IN ( SELECT a FROM t2 )", packet_length=46) at /data/src/10.0/sql/sql_parse.cc:1296

#19 0x0000000000645d55 in do_command (thd=0x7f397b757070) at /data/src/10.0/sql/sql_parse.cc:999

#20 0x0000000000765db4 in do_handle_one_connection (thd_arg=0x7f397b757070) at /data/src/10.0/sql/sql_connect.cc:1377

#21 0x0000000000765b26 in handle_one_connection (arg=0x7f397b757070) at /data/src/10.0/sql/sql_connect.cc:1292

#22 0x0000000000a00c4e in pfs_spawn_thread (arg=0x7f397b707670) at /data/src/10.0/storage/perfschema/pfs.cc:1861

#23 0x00007f3988cce064 in start_thread (arg=0x7f3989088700) at pthread_create.c:309

#24 0x00007f39870f462d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

commit 415faa122b9c683661dafac82fff414fa6864151 f83d9e4217827b4d0b078bc93dff7d8f173adbef

Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>

Date:   Thu Oct 1 07:45:27 2015 +0530

    Bug #19434916: FATAL_SIGNAL IN ADD_KEY_EQUAL_FIELDS() WITH

                   UPDATE VIEW USING OUTER SUBQUERY

    Issue:

    -----

    While resolving a column which refers to a table/view in an

    outer query, it's respecitve item object is marked with the

    outer query's select_lex object. But when the column refers

    to a view or if the column is part of a subquery in the

    HAVING clause, an Item_ref object is created. While the

    reference to the outer query is stored by the Item_ref

    object, the same is not stored in it's real_item.

    This creates a problem with the IN-TO-EXISTS optmization.

    When there is an index over the column in the inner query,

    it will be considered since the column's real_item object

    will be mistaken for a local field. This will lead to a

    crash.

    SOLUTION:

    ---------

    Under the current design, the only way to fix this issue is

    to check the reginfo.join_tab for a NULL value. If yes, the

    query should not be worrying about the key use.

    The testcase and comments added as part of the fix for

    Bug#17766653 have been backported.