Igor Babaev (Inactive) added a comment - 2021-03-26 06:53 Here's how the server is brought to the reported crash. When executing the first call of sp1() the function Multiupdate_prelocking_strategy::handle_end() comes to the code: if (select_lex->handle_derived(thd->lex, DT_MERGE)) DBUG_RETURN(1); if (thd->lex->save_prep_leaf_tables()) that merges the specification of the view v2 into update (t1 join v2 on v2.c0 = t1.c1) set v2.pk = 1; with the function mysql_derived_merge(). When doing this the function checks the validity of on expression v2.c0 = t1.c1 after having merged the select of v2 into the join of the update statement. When the function discovers that t1.c1 refers to non-existing field it reports an error and returns to Multiupdate_prelocking_strategy::handle_end() that quits immediately without calling save_prep_leaf_tables(). After this we have: v2->merged == true thd->lex->prep_leaf_list_state != SAVED <select_for_update>->first_cond_optimization == true. When executing the second call of sp1() Multiupdate_prelocking_strategy::handle_end() comes to the code if (mysql_handle_derived(lex, DT_INIT) || mysql_handle_derived(lex, DT_MERGE_FOR_INSERT) || mysql_handle_derived(lex, DT_PREPARE)) DBUG_RETURN(1); if (setup_tables_and_check_access(thd, &select_lex->context, &select_lex->top_join_list, table_list, select_lex->leaf_tables, FALSE, UPDATE_ACL, SELECT_ACL, FALSE)) DBUG_RETURN(1); The call of mysql_handle_derived(lex, DT_PREPARE) does not assign v2->table anything because v2 has been merged. The following call of setup_tables_and_check_access() sees that <select_for_update>->first_cond_optimization == true <select_for_update>->prep_leaf_list_state != SELECT_LEX::SAVED and build the list <select_for_update>->leaf_tables as containing t1,v2. The call select_for_update->handle_derived(thd->lex, DT_MERGE) does not do anything because v2 is merged. Now we come to the call of unsafe_key_update() with the list of t1,v2 as the the first parameter and the valueof v2->table == NULL. The attempt to get v2->table->map causes a crash.

Igor Babaev (Inactive) added a comment - 2021-04-03 19:32 A similar test case with multi-table delete demonstrates just a minor promlem: MariaDB [test]> create procedure sp1() delete t1 from t1 join v2 on v2.c0 = t1.c1; Query OK, 0 rows affected (0.00 sec) MariaDB [test]> call sp1(); ERROR 1054 (42S22): Unknown column 't1.c1' in 'from clause' MariaDB [test]> call sp1(); ERROR 1054 (42S22): Unknown column 't1.c1' in 'on clause' We see that the first and the second call of sp1 report errors with slightly different error messages.

Igor Babaev (Inactive) added a comment - 2021-04-07 02:07 The following change fixes the reported problem: diff --git a/sql/sql_derived.cc b/sql/sql_derived.cc index be5905d..85d67a1 100644 --- a/sql/sql_derived.cc +++ b/sql/sql_derived.cc @@ -435,6 +435,7 @@ bool mysql_derived_merge(THD *thd, LEX *lex, TABLE_LIST *derived) derived->on_expr= expr; derived->prep_on_expr= expr->copy_andor_structure(thd); } + thd->where= "on clause"; if (derived->on_expr && ((!derived->on_expr->fixed && derived->on_expr->fix_fields(thd, &derived->on_expr)) || diff --git a/sql/sql_update.cc b/sql/sql_update.cc index 01743a6..fe2421a 100644 --- a/sql/sql_update.cc +++ b/sql/sql_update.cc @@ -1395,10 +1395,8 @@ bool Multiupdate_prelocking_strategy::handle_end(THD *thd) FALSE, UPDATE_ACL, SELECT_ACL, FALSE)) DBUG_RETURN(1); - if (select_lex->handle_derived(thd->lex, DT_MERGE)) - DBUG_RETURN(1); - - if (thd->lex->save_prep_leaf_tables()) + bool rc= select_lex->handle_derived(thd->lex, DT_MERGE); + if (thd->lex->save_prep_leaf_tables() || rc) DBUG_RETURN(1); List<Item> *fields= &lex->select_lex.item_list; After having applied this diff we have: MariaDB [test]> create table t1 (id int) engine=myisam; Query OK, 0 rows affected (0.01 sec) MariaDB [test]> insert into t1 values (1),(2),(1); Query OK, 3 rows affected (0.00 sec) Records: 3 Duplicates: 0 Warnings: 0 MariaDB [test]> create table t2 (pk int, c0 int) engine=myisam; Query OK, 0 rows affected (0.00 sec) MariaDB [test]> insert into t2 values (1,1), (2,3); Query OK, 2 rows affected (0.00 sec) Records: 2 Duplicates: 0 Warnings: 0 MariaDB [test]> create view v2 as select * from t2; Query OK, 0 rows affected (0.01 sec) MariaDB [test]> create procedure sp1() update (t1 join v2 on v2.c0 = t1.c1) set v2.pk = 1; Query OK, 0 rows affected (0.00 sec) MariaDB [test]> call sp1(); ERROR 1054 (42S22): Unknown column 't1.c1' in 'on clause' MariaDB [test]> call sp1(); ERROR 1054 (42S22): Unknown column 't1.c1' in 'on clause' However in debugger we see that for the first call of sp1 the bug is reported after the call of fix_fields() for the ON expression in the function mysql_derived_merge() while for the second call of sp1 it happens when after fix_fields() for the ON expression is called in setup_on_expr(). If we check where this error message is reported for the procedure with SELECT instead of UPDATE create procedure sp0() select * from t1 join v2 on v2.c0 = t1.c1; we see that for both calls of sp0() it happens when fix_fields() for ON expression is called in setup_on_expr(). We also see that for the following SP create procedure sp2() update ((t1 join v2 on v2.c0 = t1.c1) join v2 as v on v.c0 = t1.c2) set v2.pk = 1; the first and the second calls of sp2 report different error messages MariaDB [test]> call sp2(); ERROR 1054 (42S22): Unknown column 't1.c1' in 'on clause' MariaDB [test]> call sp2(); ERROR 1054 (42S22): Unknown column 't1.c2' in 'on clause' So the suggested fix cannot be considered as satisfactory.

Oleksandr Byelkin added a comment - 2021-04-22 18:37 OK to push