Bug #49103 Deadlock between various INFORMATION_SCHEMA queries
Submitted: 25 Nov 2009 15:16 Modified: 11 Jan 2013 13:50
Reporter: Philip Stoev Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Information schema Severity:S2 (Serious)
Version:next-mr-bugfixing, mysql-5.1 OS:Any
Assigned to: CPU Architecture:Any

[25 Nov 2009 15:16] Philip Stoev
Description:
Running the RQG grammar devoted to exhaustive testing of INFORMATION_SCHEMA produced a deadlock with various threads hanging in various stages of evaluating an INFORMATION_SCHEMA query.

In addition, no new connections are accepted, so the entire server effectively hanged.

How to repeat:
The log with backtraces is here

http://pb2.norway.sun.com/web.py?action=archive_download&archive_id=1002404&pretty=please

source:

http://trollheim.norway.sun.com/archive/1001879.mysql-5.6.0-beta.tar.gz

binary:

http://trollheim.norway.sun.com/archive/1001972.mysql-5.6.0-beta-linux-i686.tar.gz

core:

http://trollheim.norway.sun.com/archive/1002403.mysql-5.6.0-beta-linux-i686-test.tar.gz
[25 Nov 2009 15:17] Philip Stoev
bug 49103 threads

Attachment: bug49103.threads.txt (text/plain), 40.90 KiB.

[2 Jan 2010 0:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2 Jan 2010 14:37] Philip Stoev
Also repeatable with mysql-5.1 .
[2 Jan 2010 14:43] Philip Stoev
Some thread is holding LOCK_global_system_variables -- the server is totally hosed, no new clients can connect, because they hang with the following backtrace:

#0  0x000000315b00db14 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x000000315b00921c in _L_lock_1078 () from /lib64/libpthread.so.0
#2  0x000000315b0090f0 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00000000009cdbc4 in safe_mutex_lock (mp=0xfa2b60, try_lock=0 '\0',
    file=0xabacd4 "sql_class.cc", line=806) at thr_mutex.c:149
#4  0x00000000006312bd in THD::init (this=0x31e1f88) at sql_class.cc:806
#5  0x0000000000631d16 in THD (this=0x31e1f88) at sql_class.cc:674
#6  0x0000000000648b23 in handle_connections_sockets (arg=0x0)
    at mysqld.cc:5185
#7  0x000000000064c0ec in main (argc=45, argv=0x7fffe1053be8) at mysqld.cc:4538
[11 Jan 2013 13:50] Praveenkumar Hulakund
Here, one of the lock involved in the dead lock cycle is
"LOCK_event_metadata".
And this lock itself is removed in the patch for bug#51160.
Because of this the deadlock scenario mentioned in this bug report
will not occur.

Patch for the bug#51160 is pushed in 5.1+ versions.

So, This issue is fixed in 5.1+ versions.
[15 Jan 2013 8:54] Praveenkumar Hulakund
Here, one of the lock involved in the dead lock cycle is
"LOCK_event_metadata".
And this lock itself is removed in the patch for bug#51160.
Because of this the deadlock scenario mentioned in this bug report
will not occur.

Patch for the bug#51160 is pushed in 5.5 version.

So, This issue is fixed in 5.5+ versions.