MySQL Bugs: #48152: assert in MDL_context::wait_for

Bug #48152	assert in MDL_context::wait_for_locks
Submitted:	19 Oct 2009 14:47	Modified:	8 Jan 2010 14:04
Reporter:	Matthias Leich	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: Locking	Severity:	S3 (Non-critical)
Version:	mysql-6.0-codebase-bugfixing	OS:	Any
Assigned to:	Philip Stoev	CPU Architecture:	Any
Tags:	mdl

Description:
The assert happens in mdl.cc:1243
  DBUG_ASSERT(mdl_request != mdl_request->next_in_list);

Backtrace from mysql-6.0-codebase-bugfixing 
revno: 3654 2009-10-15
-------------------------------------------
Thread 1 (process 19620):
#0  0x00007fc5a5d731f6 in pthread_kill () from /lib/libpthread.so.0
#1  0x0000000000b8f05c in my_write_core (sig=6) at stacktrace.c:309
#2  0x00000000006f6f17 in handle_segfault (sig=6) at mysqld.cc:2754
#3  <signal handler called>
#4  0x00007fc5a4c27fb5 in raise () from /lib/libc.so.6
#5  0x00007fc5a4c29bc3 in abort () from /lib/libc.so.6
#6  0x00007fc5a4c20f09 in __assert_fail () from /lib/libc.so.6
#7  0x000000000094840b in MDL_context::wait_for_locks (this=0x3b9c020, mdl_requests=0x7fc59941dfa0) at mdl.cc:1243
#8  0x0000000000766365 in Open_table_context::recover_from_failed_open_table_attempt (this=0x7fc59941dfa0, thd=0x3b9bf48, table=0x7fc59941e090) at sql_base.cc:3696
#9  0x0000000000767b66 in open_ltable (thd=0x3b9bf48, table_list=0x7fc59941e090, lock_type=TL_WRITE, lock_flags=0) at sql_base.cc:4653
#10 0x0000000000767fe1 in open_system_table_for_update (thd=0x3b9bf48, one_table=0x7fc59941e090) at sql_base.cc:8646
#11 0x000000000091300b in open_proc_table_for_update (thd=0x3b9bf48) at sp.cc:270
#12 0x00000000009137f2 in sp_create_routine (thd=0x3b9bf48, type=2, sp=0x38e3ea0) at sp.cc:758
#13 0x000000000090b683 in sp_head::create (this=0x38e3ea0, thd=0x3b9bf48) at sp_head.cc:731
#14 0x0000000000710a6c in mysql_execute_command (thd=0x3b9bf48) at sql_parse.cc:4274
#15 0x0000000000712b87 in mysql_parse (thd=0x3b9bf48, inBuf=0x3c58f70 "CREATE PROCEDURE testdb_N . p1_2_N  () BEGIN SELECT `pk`,`int`,`int_key` FROM A ; SELECT `pk`,`int`,`int_key` FROM A ; END", length=122,
     found_semicolon=0x7fc599420900) at sql_parse.cc:5991
#16 0x00000000007137d2 in dispatch_command (command=COM_QUERY, thd=0x3b9bf48,
    packet=0x3bae849 "CREATE PROCEDURE testdb_N . p1_2_N  () BEGIN SELECT `pk`,`int`,`int_key` FROM A ; SELECT `pk`,`int`,`int_key` FROM A ; END", packet_length=122) at sql_parse.cc:1074
#17 0x0000000000714d3d in do_command (thd=0x3b9bf48) at sql_parse.cc:756
#18 0x0000000000701784 in handle_one_connection (arg=0x3b9bf48) at sql_connect.cc:1164
#19 0x00007fc5a5d6e3ba in start_thread () from /lib/libpthread.so.0
#20 0x00007fc5a4cdafcd in clone () from /lib/libc.so.6
#21 0x0000000000000000 in ?? ()

The assertion happens in RQG tests with
- 30 threads
- a grammar derived from WL5004_sql.yy

I will come up with a simplified replay testcase soon.

How to repeat:
See above

Bug #47770 has been marked as a duplicate to this one. The assertion is

DBUG_ASSERT(mdl_request != mdl_request->next_in_list)

and was added on purpose in order to convert a 100% CPU loop+deadlock (bug 47770) into a manageable assertion (bug 48152).

The grammar simplification was not successful.
I will restart the simplification if I have the time.

Reassigning to Philip and setting this bug to "Need Feedback".
Is it still reproducable?
If it is, any more info (e.g. core files) would be helpful.

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".

Closing the bug as "Can't repeat" after discussing with Philip.
The bug has not been seen since October.