• unknown's avatar
    A fix for Bug#19022 "Memory bug when switching db during trigger execution". · 17f77591
    unknown authored
    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.
    17f77591
slave.cc 166 KB