bzr commit into mysql-6.0 branch (davi:2649) Bug#36579

[Davi Arnaut]

# At a local mysql-6.0 repository of davi

 2649 Davi Arnaut	2008-06-10
      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	2008-04-09 01:07:00 +0000
+++ b/mysys/thr_lock.c	2008-06-10 12:38: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");
-  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;
 }