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.
This commit is contained in:
parent
c546559a62
commit
1ee4a3ac82
@ -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;
|
||||
}
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user