MDEV-15816

To make it easier for debug, I can reproduce this bug just as below steps.

client 1:
USE test;
CREATE TABLE t1 (i INT) ENGINE=MyISAM;
HANDLER t1 OPEN h;
CREATE TABLE t2 (i INT) ENGINE=RocksDB;
LOCK TABLES t2 WRITE;

client 2:
FLUSH TABLES WITH READ LOCK;

client 1:
INSERT INTO t2 VALUES (1);

“HANDLER t1 OPEN h;” is the key step to reproduce this bug, because it sets needs_thr_lock_abort to true in THD::notify_shared_lock(…)

#0  MDL_context::set_needs_thr_lock_abort (this=0x2c8b608, needs_thr_lock_abort=true) at /workspace/mysql/sql/mdl.h:819
#1  0x0000000000fbae79 in mysql_ha_open_table (thd=0x2c8b520, hash_tables=0x7fffdc01a070) at /workspace/mysql/sql/sql_handler.cc:358
#2  0x0000000000fbaa68 in Sql_cmd_handler_open::execute (this=0x7fffdc005c88, thd=0x2c8b520) at /workspace/mysql/sql/sql_handler.cc:265
#3  0x0000000000fec871 in mysql_execute_command (thd=0x2c8b520, statement_start_time=0x7ffff7e8d868, post_parse=0x7ffff7e8e9e8) at /workspace/mysql/sql/sql_parse.cc:6209
#4  0x0000000000ff06b9 in mysql_parse (thd=0x2c8b520, rawbuf=0x7fffdc005630 "HANDLER t1 OPEN h", length=17, parser_state=0x7ffff7e8e280, last_timer=0x7ffff7e8e9e8, 
async_commit=0x7ffff7e8e9e7 "") at /workspace/mysql/sql/sql_parse.cc:7895
#5  0x0000000000fe128c in dispatch_command (command=COM_QUERY, thd=0x2c8b520, packet=0x2c9de21 "HANDLER t1 OPEN h", packet_length=17) at /workspace/mysql/sql/sql_parse.cc:1919
#6  0x0000000000fdf303 in do_command (thd=0x2c8b520) at /workspace/mysql/sql/sql_parse.cc:1193
#7  0x0000000000f9fdb7 in do_handle_one_connection (thd_arg=0x2c8b520) at /workspace/mysql/sql/sql_connect.cc:1142
#8  0x0000000000f9f859 in handle_one_connection (arg=0x2c8b520) at /workspace/mysql/sql/sql_connect.cc:963
#9  0x00007ffff7bc6e25 in start_thread () from /lib64/libpthread.so.0
#10 0x00007ffff5d2e34d in clone () from /lib64/libc.so.6

Then “FLUSH TABLES WITH READ LOCK;” calls THD::notify_shared_lock() which checks “needs_thr_lock_abort” and then calls mysql_lock_abort_for_thread().