Bug#19941403: FATAL_SIGNAL(SIG 6) IN BUILD_EQUAL_ITEMS_FOR_COND | IN SQL/SQL_OPTIMIZER.CC:1657

Problem:
At the end of first execution select_lex->prep_where is pointing to
a runtime created object (temporary table field). As a result
server exits trying to access a invalid pointer during second
execution.

Analysis:
While optimizing the join conditions for the query, after the
permanent transformation, optimizer makes a copy of the new
where conditions in select_lex->prep_where. "prep_where" is what
is used as the "where condition" for the query at the start of execution.
W.r.t the query in question, "where" condition is actually pointing
to a field in the temporary table. As a result, for the  second
execution the pointer is no more valid resulting in server exit.

Fix:
At the end of the first execution, select_lex->where will have the
original item of the where condition.
Make prep_where the new place where the original item of select->where
has to be rolled back.
Fixed in 5.7 with the wl#7082 - Move permanent transformations from
JOIN::optimize to JOIN::prepare

Patch for 5.5 includes the following backports from 5.6:

Bugfix for Bug12603141 - This makes the first execute statement in the testcase
pass in 5.5

However it was noted later in in Bug16163596 that the above bugfix needed to
be modified. Although Bug16163596 is reproducible only with changes done for
Bug12582849, we have decided include the fix.

Considering that Bug12582849 is related to Bug12603141, the fix is
also included here. However this results in Bug16317817, Bug16317685,
Bug16739050. So fix for the above three bugs is also part of this patch.

1 files changed, 16 insertions, 0 deletions

diff --git a/sql/sql_class.h b/sql/sql_class.h
index 5a5e8b48754..c9900231615 100644
--- a/sql/sql_class.h
+++ b/sql/sql_class.h
@@ -2515,6 +2515,22 @@ public:
       nocheck_register_item_tree_change(place, *place, mem_root);
     *place= new_value;
   }
+
+  /*
+    Find and update change record of an underlying item.
+
+    @param old_ref The old place of moved expression.  @param new_ref The
+    new place of moved expression.  @details During permanent
+    transformations, e.g. join flattening in simplify_joins, a condition
+    could be moved from one place to another, e.g. from on_expr to WHERE
+    condition. If the moved condition has replaced some other with
+    change_item_tree() function, the change record will restore old value to
+    the wrong place during rollback_item_tree_changes. This function goes
+    through the list of change records, and replaces
+    Item_change_record::place.
+  */
+  void change_item_tree_place(Item **old_ref, Item **new_ref);
+
   void nocheck_register_item_tree_change(Item **place, Item *old_value,
                                          MEM_ROOT *runtime_memroot);
   void rollback_item_tree_changes();