From 16141e0c8591736197c4b74dc3f9c0e7ca85b12b Mon Sep 17 00:00:00 2001
From: Luis Soares <luis.soares@sun.com>
Date: Thu, 24 Jun 2010 19:03:23 +0100
Subject: [PATCH] BUG#54509: rpl_show_slave_running crashes the server
 sporadically

Problem: SQL and IO thread were racing for the IO_CACHE. The former to
flush it, the latter to close it. In some cases this would cause the
SQL thread to lock an invalid IO_CACHE mutex (it had been destroyed by
IO thread). This would happen when SQL thread was initializing the
master.info

Solution: We solve this by locking the log and checking if it is
hot. If it is we keep the log while seeking. Otherwise we release it
right away, because a log can get from hot to cold, but not from cold
to hot.
---
 sql/rpl_mi.cc | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/sql/rpl_mi.cc b/sql/rpl_mi.cc
index 9b0450b3f02..443af94e0d0 100644
--- a/sql/rpl_mi.cc
+++ b/sql/rpl_mi.cc
@@ -164,7 +164,29 @@ int init_master_info(Master_info* mi, const char* master_info_fname,
     */
     if (thread_mask & SLAVE_SQL)
     {
+      bool hot_log= FALSE;
+      /* 
+         my_b_seek does an implicit flush_io_cache, so we need to:
+
+         1. check if this log is active (hot)
+         2. if it is we keep log_lock until the seek ends, otherwise 
+            release it right away.
+
+         If we did not take log_lock, SQL thread might race with IO
+         thread for the IO_CACHE mutex.
+
+       */
+      mysql_mutex_t *log_lock= mi->rli.relay_log.get_log_lock();
+      mysql_mutex_lock(log_lock);
+      hot_log= mi->rli.relay_log.is_active(mi->rli.linfo.log_file_name);
+
+      if (!hot_log)
+        mysql_mutex_unlock(log_lock);
+
       my_b_seek(mi->rli.cur_log, (my_off_t) 0);
+
+      if (hot_log)
+        mysql_mutex_unlock(log_lock);
     }
     DBUG_RETURN(0);
   }