BUG#19897405: CRASH WHILE ACCESSING VIEWS IN STORED ROUTINE

              AND TABLES ARE FLUSHED

Analysis
--------
The server crashes while accessing view columns in the
stored procedure after DDL/FLUSH TABLE operation
is performed on the tables used by the SQL statements
in the stored procedure.

Scenario 1:

a) SP is executed--> The view fields are resolved/fixed.
b) Trigger reparse--> Query arena state is not reset and
   remains as 'STMT_EXECUTED'.
c) SP is executed--> The view fields are resolved/fixed
   using the execution mem_root.
d) SP is executed--> Server crashes while trying to
   access the resolved view columns allocated on the
   execution mem_root which was freed after execution(c).

Scenario 2:

a) SP is executed--> The view fields are resolved/fixed.
b) Trigger reparse--> Query arena state is reset with
   the fix introduced in the earlier patch for scenario 1.
c) SP is executed--> DDL execution fails--> View fields
   are not resolved/fixed--> But query arena state is set
   as 'STMT_EXECUTED'.
d) SP is executed--> The view fields are resolved/fixed
   using the execution mem_root.
e) SP is executed--> Server crashes while trying to
   access the resolved view columns allocated on the
   execution mem_root which was freed after execution(d).

The DDL/FLUSH TABLE operation on the tables used by the
SQL statement of the stored procedure triggers a
re-parse of the query. The state of the statement arena
was set to 'STMT_EXECUTED'. Also when the DDL fails,
beyond the open table stage during execution, the
state of the statement arena was set to 'STMT_EXECUTED'.
This state of the query arena caused the runtime arena
to be used for the allocation of item representing the
view column instead of persistent arena. The runtime
arena and the mem_root associated with it is not
persistent and is deallocated at the end of the query
execution. Hence the subsequent execution of the stored
procedure, accesses invalid(freed) memory causing the
server to crash.

Fix:
---
The condition which checks the state of the query arena
for the allocation of the item representing the view
column in an appropriate mem_root is removed.
Since there is already a condition to determine whether
the statement is a prepared statement or stored routine
statement for switching to a persistent mem_root.

Thus, when the item representing the view column is created,
it will be allocated on the persistent memroot which will be
accessible for the subsequent calls to the stored procedure.

Note: This is a follow up patch.

Author: Nisha Gopalakrishnan

sql/sql_base.cc

@@ -6553,10 +6553,7 @@ find_field_in_view(THD *thd, TABLE_LIST *table_list,
           Use own arena for Prepared Statements or data will be freed after
           PREPARE.
         */
-        Prepared_stmt_arena_holder ps_arena_holder(
-          thd,
-          register_tree_change &&
-            thd->stmt_arena->is_stmt_prepare_or_first_stmt_execute());
+        Prepared_stmt_arena_holder ps_arena_holder(thd, register_tree_change);
 
         /*
           create_item() may, or may not create a new Item, depending on