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.

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.

1 files changed, 1 insertions, 1 deletions

diff --git a/mysys/thr_lock.c b/mysys/thr_lock.c
index 02c9f08c946..853e1f96b49 100644
--- a/mysys/thr_lock.c
+++ b/mysys/thr_lock.c
@@ -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;
 }