From: Date: August 25 2008 3:19pm
Subject: bzr commit into mysql-5.0 branch (davi:2673) Bug#36579
List-Archive: http://lists.mysql.com/commits/52455
X-Bug: 36579
Message-Id: <20080825131902.C4A44EC298@skynet.ctb.virtua.com.br>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

# At a local mysql-5.0 repository of davi

 2673 Davi Arnaut	2008-08-25
      Bug#36579 Dumping information about locks in use may lead to a server crash
      
      Dumping information about locks in use by sending a SIGHUP signal
      to the server or by invoking the "mysqladmin debug" command may
      lead to a server crash in debug builds or to undefined behavior in
      production builds.
      
      The problem was that a mutex that protects a lock object (THR_LOCK)
      might have been destroyed before the lock object was actually removed
      from the list of locks in use, causing a race condition with other
      threads iterating over the list. The solution is to destroy the mutex
      only after removing lock object from the list.
modified:
  mysys/thr_lock.c

per-file messages:
  mysys/thr_lock.c
    Destroy the mutex that protects the lock object only after removing
    the lock object from the list of locks in use.
=== modified file 'mysys/thr_lock.c'
--- a/mysys/thr_lock.c	2007-08-05 09:17:07 +0000
+++ b/mysys/thr_lock.c	2008-08-25 13:18:52 +0000
@@ -333,10 +333,10 @@ void thr_lock_init(THR_LOCK *lock)
 void thr_lock_delete(THR_LOCK *lock)
 {
   DBUG_ENTER("thr_lock_delete");
-  VOID(pthread_mutex_destroy(&lock->mutex));
   pthread_mutex_lock(&THR_LOCK_lock);
   thr_lock_thread_list=list_delete(thr_lock_thread_list,&lock->list);
   pthread_mutex_unlock(&THR_LOCK_lock);
+  pthread_mutex_destroy(&lock->mutex);
   DBUG_VOID_RETURN;
 }