bzr push into mysql-5.0 branch (davi:2672 to 2673) Bug#36579

[Davi Arnaut]

 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

 2672 Sergey Glukhov	2008-08-25
      Bug#37428 Potential security issue with UDFs - linux shellcode execution.
      plugin_dir option backported from 5.1
modified:
  mysql-test/r/udf.result
  sql/mysql_priv.h
  sql/mysqld.cc
  sql/set_var.cc
  sql/sql_udf.cc
  sql/unireg.h

=== 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;
 }