Igor Babaev (Inactive) added a comment - 2018-08-21 23:35 - edited We have a similar failure for the following prepare statement   prepare stmt from "CREATE VIEW v1 AS WITH cte1 AS (SELECT * FROM (SELECT 1) AS A) SELECT * FROM cte1;" ;   prepare stmt from "DO (SELECT 1 FROM (WITH cte1 AS (SELECT * FROM (SELECT 1) AS A) SELECT * FROM cte1) t);" ;   prepare stmt from "SET @a = (SELECT 1 FROM (WITH cte1 AS (SELECT * FROM (SELECT 1) AS A) SELECT * FROM cte1) t);" ; This sequence of commands triggers the same assertion failure create table t1 (a int ); create procedure p (i int ) insert into t1 values (i); prepare stmt from "CALL p ((SELECT 1 FROM (WITH cte1 AS (SELECT * FROM (SELECT 1) AS A) SELECT * FROM cte1) t));" ;

Igor Babaev (Inactive) added a comment - 2018-08-22 22:20 - edited This bug happens because the calls open_normal_and_derived_tables() in the functions - mysql_test_create_table() - mysql_test_create_view() - mysql_test_do_fields() - mysql_test_set_fields() - mysql_test_call_fields() lack the flag DT_INIT in the last parameter. So the function mysql_handle_derived() called by open_normal_and_derived_tables() gets as the second parameter the flags with DT_PREPARE, but without DT_INIT. In this case mysql_handle_derived() first iterates over SELECTs of the statements and for each table reference from the FROM list of a given SELECT it calls mysql_derived_prepare(). If the table reference passed to mysql_derived_prepare() happens to be a reference to a derived table then the function mysql_derived_prepare() starts performing semantic analysis of the unit specifying the derived table. At the beginning of this analysis for each SELECT from the specification the function calls the method st_select_lex::handle_derived() with the flag DT_PREPARE. The method iterates over the table references from the FROM list of the SELECT for which it has been called. If a table reference happens to be a reference to a derived table dt (or view) the method calls TABLE_LIST::handle_derived(). The latter first performs semantic analysis of the derived tables referred in the specification of dt and then calls mysql_handle_single_derived() that in its turn calls mysql_derived_prepare() for dt.

Alice Sherepa added a comment - 2018-08-31 10:53 - edited adding just to make it searchable, got the same assertion, does not fail after d8b8079e421a7d19d3e0 commit mysqld: /10.3/sql/table.cc:6017: void Field_iterator_table_ref::set_field_iterator(): Assertion `table_ref->table || table_ref->view' failed. 180831 12:10:32 [ERROR] mysqld got signal 6 ; Server version: 10.3.10-MariaDB-debug-log sql/table.cc:6018(Field_iterator_table_ref::set_field_iterator())[0x55c23e119582] sql/table.cc:6035(Field_iterator_table_ref::set(TABLE_LIST*))[0x55c23e11998b] sql/sql_base.cc:6652(mark_common_columns(THD*, TABLE_LIST*, TABLE_LIST*, List<String>*, unsigned int*))[0x55c23dd3f6b9] sql/sql_base.cc:7054(store_top_level_join_columns(THD*, TABLE_LIST*, TABLE_LIST*, TABLE_LIST*))[0x55c23dd418a6] sql/sql_base.cc:7176(setup_natural_join_row_types(THD*, List<TABLE_LIST>*, Name_resolution_context*))[0x55c23dd4212e] sql/sql_base.cc:7593(setup_tables(THD*, Name_resolution_context*, List<TABLE_LIST>*, TABLE_LIST*, List<TABLE_LIST>&, bool, bool))[0x55c23dd4531e] sql/sql_base.cc:7636(setup_tables_and_check_access(THD*, Name_resolution_context*, List<TABLE_LIST>*, TABLE_LIST*, List<TABLE_LIST>&, bool, unsigned long, unsigned long, bool))[0x55c23dd45550] sql/sql_select.cc:1009(JOIN::prepare(TABLE_LIST*, unsigned int, Item*, unsigned int, st_order*, bool, st_order*, Item*, st_order*, st_select_lex*, st_select_lex_unit*))[0x55c23df06c77] sql/sql_union.cc:654(st_select_lex_unit::prepare_join(THD*, st_select_lex*, select_result*, unsigned long, bool))[0x55c23e0b45b9] sql/sql_union.cc:977(st_select_lex_unit::prepare(TABLE_LIST*, select_result*, unsigned long))[0x55c23e0b73fb] sql/sql_derived.cc:766(mysql_derived_prepare(THD*, LEX*, TABLE_LIST*))[0x55c23ddcb5b8] sql/sql_derived.cc:121(mysql_handle_derived(LEX*, unsigned int))[0x55c23ddc83be] sql/sql_base.cc:5012(open_normal_and_derived_tables(THD*, TABLE_LIST*, unsigned int, unsigned int))[0x55c23dd369a1] sql/sql_prepare.cc:2027(mysql_test_create_view(Prepared_statement*))[0x55c23dec6851] sql/sql_prepare.cc:2413(check_prepared_statement(Prepared_statement*))[0x55c23dec7f9f] sql/sql_prepare.cc:3984(Prepared_statement::prepare(char const*, unsigned int))[0x55c23ded083f] sql/sql_prepare.cc:2817(mysql_sql_stmt_prepare(THD*))[0x55c23dec9b81] sql/sql_parse.cc:3781(mysql_execute_command(THD*))[0x55c23de753b4] sql/sp_head.cc:3594(sp_instr_stmt::exec_core(THD*, unsigned int*))[0x55c23dc990f0] sql/sp_head.cc:3322(sp_lex_keeper::reset_lex_and_exec_core(THD*, unsigned int*, bool, sp_instr*))[0x55c23dc97a23] sql/sp_head.cc:3500(sp_instr_stmt::execute(THD*, unsigned int*))[0x55c23dc988d8] sql/sp_head.cc:1354(sp_head::execute(THD*, bool))[0x55c23dc8bca7] sql/sp_head.cc:2294(sp_head::execute_procedure(THD*, List<Item>*))[0x55c23dc90e69] sql/sql_parse.cc:2949(do_execute_sp(THD*, sp_head*))[0x55c23de6fe8b] sql/sql_parse.cc:3191(Sql_cmd_call::execute(THD*))[0x55c23de718c8] sql/sql_parse.cc:6285(mysql_execute_command(THD*))[0x55c23de84906] sql/sql_parse.cc:8089(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x55c23de8f529] sql/sql_parse.cc:1852(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x55c23de6a15f] sql/sql_parse.cc:1395(do_command(THD*))[0x55c23de672f7] sql/sql_connect.cc:1402(do_handle_one_connection(CONNECT*))[0x55c23e1b863a] sql/sql_connect.cc:1309(handle_one_connection)[0x55c23e1b8017] perfschema/pfs.cc:1864(pfs_spawn_thread)[0x55c23f4d394d] /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f9c093866ba] x86_64/clone.S:111(clone)[0x7f9c0881b41d]

Igor Babaev (Inactive) added a comment - 2018-09-07 03:12 - edited Here's the explanation why the reported statement fail in 10.4 and do not fail in 10.2 and 10.2. In 10.4 for the first reported statement prepare stmt from "CREATE TABLE t1 AS WITH cte(a) AS (SELECT * FROM (SELECT 1) AS t) SELECT * FROM cte;"; The order of SELECTs in LEX::all_select_list is as follows: select `*` AS `*` from cte select 1 AS `1 select `*` AS `*` from (select 1 AS `1`) t This order determines the order in which context analysis of SELECTs is performed. Thus mysql_derived_prepare() first is called for the derived tables of select ` ` AS ` ` from cte. As ''cte' is identified a CTE table mysql_prepare_derived() is called for 'cte'. This call leads to a call of st_select_lex::handle_derived for select ` ` AS ` ` from (select 1 AS `1`) t. The table t is a derived table, yet it 's not marked as such. So mysql_prepare_derived()is not called for t and we have a crash in setup_wild() for select ` ` AS ` ` from (select 1 AS `1`) t. In 10.2 we have the following order of SELECTs in LEX::all_select_list ; select 1 AS `1` select `*` AS `*` from (select 1 AS `1`) t select `*` AS `*` from cte Here mysql_derived_prepare() first is called for the derived tables of select ` ` AS ` ` from (select 1 AS `1`) t. In this case t is not marked as derived, mysql_derived_prepare() sees that there is a unit specifying this table. So t is handled as derived and a call of TABLE_LIST::init() derived marks it as such.

Igor Babaev (Inactive) added a comment - 2018-09-07 19:48 A fix for this bug was pushed into 10.2,10.3,10.4. It makes sense to to port the fix without test case to 5.5,10.0,10.1