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.
Showing
Please register or sign in to comment