Bug #34305 show slave status handling segfaults when slave io is about

    to leave

The artifact was caused by
a flaw in concurrent accessing the slave's io thd by
the io itself and a handling show slave status thread.
Namely, show_master_info did not acquire mi->run_lock mutex that is
specified for mi->io_thd member.

Fixed with deploying the mutex locking and unlocking. The mutex is kept
short time and without interleaving with mi->data_lock mutex.

Todo: to report and fix an issue with 
    sys_var_slave_skip_counter::{methods} 
seem to acquire incorrectly
     active_mi->rli.run_lock
instead of the specified
     active_mi->rli.data_lock

A test case is difficult to compose, so rpl_packet should continue serving
as the indicator.


sql/slave.cc:
  implementing a TODO left at 4.1 time:
  mending access to mi->io_thd with the specified mutex;
sql/slave.h:
  adding a member name to the list of that run_lock guards.

1 files changed, 6 insertions, 5 deletions

diff --git a/sql/slave.cc b/sql/slave.cc
index 4a65e9aaa85..8a3620080f2 100644
--- a/sql/slave.cc
+++ b/sql/slave.cc
@@ -2447,14 +2447,15 @@ bool show_master_info(THD* thd, MASTER_INFO* mi)
     protocol->prepare_for_resend();
   
     /*
-      TODO: we read slave_running without run_lock, whereas these variables
-      are updated under run_lock and not data_lock. In 5.0 we should lock
-      run_lock on top of data_lock (with good order).
+      slave_running can be accessed without run_lock but not other
+      non-volotile members like mi->io_thd, which is guarded by the mutex.
     */
+    pthread_mutex_lock(&mi->run_lock);
+    protocol->store(mi->io_thd ? mi->io_thd->proc_info : "", &my_charset_bin);
+    pthread_mutex_unlock(&mi->run_lock);
+
     pthread_mutex_lock(&mi->data_lock);
     pthread_mutex_lock(&mi->rli.data_lock);
-
-    protocol->store(mi->io_thd ? mi->io_thd->proc_info : "", &my_charset_bin);
     protocol->store(mi->host, &my_charset_bin);
     protocol->store(mi->user, &my_charset_bin);
     protocol->store((uint32) mi->port);