I don't think the problem is critical as such, but Monty asked to mark as 'Critical' those that need to be taken care of, and that's one of them – it's a recent regression in GA, and besides it breaks buildbot tests.

Could not reproduce on MySQL 5.5 (release or debug), or on MariaDB 5.5.28 release and on maria/5.5 revno 3592, or on maria/10.0 and 10.0-base (MDEV-3941 is not there yet).

However, I observed a different problem on release binaries of 5.5.28, both MariaDB and MySQL. The same test sometimes gets stuck, the process list shows

--------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------

And stack trace is like

Thread 3 (Thread 0x7fca79c57700 (LWP 19711)):
#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
#1 0x00000000006572d3 in inline_mysql_cond_timedwait (src_line=<optimized out>, src_file=<optimized out>, abstime=<optimized out>, mutex=<optimized out>, that=<optimized out>) at /homeinclude/mysql/psi/mysql_thread.h:1012
#2 MDL_wait::timed_wait (this=0x23e3800, thd=0x23e3710, abs_timeout=0x7fca79c54ab0, set_status_on_timeout=false, wait_state_name=<optimized out>) at /homesql/mdl.cc:1191
#3 0x0000000000659682 in MDL_context::acquire_lock (this=0x23e3800, mdl_request=0x247e240, lock_wait_timeout=140507761248984) at /homesql/mdl.cc:2103
#4 0x0000000000659ce4 in MDL_context::acquire_locks (this=0x23e3800, mdl_requests=<optimized out>, lock_wait_timeout=31536000) at /homesql/mdl.cc:2214
#5 0x0000000000549c83 in lock_table_names (thd=0x23e3710, tables_start=<optimized out>, tables_end=0x247de30, lock_wait_timeout=31536000, flags=1) at /homesql/sql_base.cc:4739
#6 0x0000000000609bc9 in mysql_rm_table (thd=0x23e3710, tables=0x247de30, if_exists=0 '\000', drop_temporary=0 '\000') at /homesql/sql_table.cc:1895
#7 0x0000000000590d53 in mysql_execute_command (thd=0x23e3710) at /homesql/sql_parse.cc:3116
#8 0x0000000000595400 in mysql_parse (thd=0x23e3710, rawbuf=0x247dd68 "DROP TABLE t1", length=<optimized out>, parser_state=0x7fca79c56620) at /homesql/sql_parse.cc:5730
#9 0x00000000005969ba in dispatch_command (command=<optimized out>, thd=0x23e3710, packet=0x24759f1 "DROP TABLE t1", packet_length=13) at /homesql/sql_parse.cc:1055
#10 0x0000000000596d5b in do_command (thd=0x23e3710) at /homesql/sql_parse.cc:794
#11 0x000000000064e274 in do_handle_one_connection (thd_arg=0x23e3710) at /homesql/sql_connect.cc:1253
#12 0x000000000064e3ac in handle_one_connection (arg=<optimized out>) at /homesql/sql_connect.cc:1168
#13 0x0000000000a6be88 in pfs_spawn_thread (arg=<optimized out>) at /homestorage/perfschema/pfs.cc:1015
#14 0x00007fca854beefc in start_thread (arg=0x7fca79c57700) at pthread_create.c:304
#15 0x00007fca84628f4d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#16 0x0000000000000000 in ?? ()

But I'm not sure it's related to the failure described in this report.

A bit modified two threaded test that fails before rev 3593 in the same way (on 3593 it fails even faster):

--disable_query_log
--disable_result_log

--let $run=1000
--connect (con1, localhost, root,,)

CREATE TABLE t1 ( f1 INTEGER AUTO_INCREMENT, PRIMARY KEY (f1)) ENGINE=MyISAM;

while ($run)
{
--echo # $run attempts left...
--send INSERT DELAYED t1 VALUES (NULL);
--connection default
--error ER_TABLE_EXISTS_ERROR
CREATE TABLE t1 AS SELECT 1 AS f1;
--connection con1
--reap
--dec $run
}
DROP TABLE t1;

--echo # All done

Actually it can fail in two ways:
1. mysqltest: At line 19: query 'reap' failed: 1317: Query execution was interrupted

or:
2. mysqltest: At line 19: query 'reap' failed: 1927: Connection was killed

My analysis:
Connection creating table sets killed= KILL_SYSTEM_THREAD state on the "delayed" thread (in function mysql_notify_thread_having_shared_lock). If there comes another delayed insert before the thread is really killed it could abort with 'Query execution was interrupted'. Before rev 3593 it is impossible (or at least a lot harder) to get into that state with only one thread issuing create table and insert delayed because create table command waits for lock that "delayed" thread has to abort.

Found and fixed the issues
It was two different bugs:
a) INSERT DELAYED + CREATE TABLE

• This was a new bug introduced by the CREATE TABLE optimization
  b) INSERT DELAYED + DROP TABLE.
• This was an old bug in 5.5 introduced with MDL locks.

Fixed both issues