A fix for Bug#19022 "Memory bug when switching db during trigger execution".

No test case as the bug is in an existing test case (rpl_trigger.test
when it is run under valgrind).
The warning was caused by memory corruption in replication slave: thd->db
was pointing at a stack address that was previously used by 
sp_head::execute()::old_db. This happened because mysql_change_db
behaved differently in replication slave and did not make a copy of the 
argument to assign to thd->db. 
The solution is to always free the old value of thd->db and allocate a new
copy, regardless whether we're running in a replication slave or not.


sql/log_event.cc:
  Move rewrite_db to log_event.cc, the only place where it is used.
sql/slave.cc:
  Move rewrite_db to log_event.cc
sql/slave.h:
  Remove an unneeded declaration.
sql/sql_class.h:
  Fix set_db to always free the old db, even if the argument is NULL.
  Add a comment.
sql/sql_db.cc:
  Always make a deep copy of the argument in mysql_change_db, even 
  if running in a replication slave. This is necessary because 
  sp_use_new_db (stored procedures) assumes that mysql_change_db always makes
  a deep copy of the argument, and thus passes a pointer to stack into it.
  This assumption was true for all cases except the replication slave thread.

1 files changed, 0 insertions, 18 deletions

diff --git a/sql/slave.cc b/sql/slave.cc
index 4da447c4bc3..b284f4a6a16 100644
--- a/sql/slave.cc
+++ b/sql/slave.cc
@@ -1177,24 +1177,6 @@ bool net_request_file(NET* net, const char* fname)
 }
 
 
-const char *rewrite_db(const char* db, uint *new_len)
-{
-  if (replicate_rewrite_db.is_empty() || !db)
-    return db;
-  I_List_iterator<i_string_pair> it(replicate_rewrite_db);
-  i_string_pair* tmp;
-
-  while ((tmp=it++))
-  {
-    if (!strcmp(tmp->key, db))
-    {
-      *new_len= (uint32)strlen(tmp->val);
-      return tmp->val;
-    }
-  }
-  return db;
-}
-
 /*
   From other comments and tests in code, it looks like
   sometimes Query_log_event and Load_log_event can have db == 0