MySQL Bugs: #98995: thread that holding lock disappear

Bug #98995	thread that holding lock disappear
Submitted:	19 Mar 2020 3:09	Modified:	19 Mar 2020 14:12
Reporter:	Zhang JiYang	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S3 (Non-critical)
Version:	5.7.26	OS:	Linux
Assigned to:		CPU Architecture:	x86

Description:
We got a crash because:
[ERROR] [FATAL] InnoDB: Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung.

Then we check the Innodb MONITOR in error log, and we see many logs look like that:
...
--Thread 140031730865920 has waited at row0undo.cc line 322 for 760.00 seconds the semaphore:
S-lock on RW-latch at 0x7f5faf05a978 created in file dict0dict.cc line 1186
a writer (thread id 140042102085376) has reserved it in mode  wait exclusive
number of readers 2, waiters flag 1, lock_word: fffffffffffffffe
Last time read locked in file row0undo.cc line 322
Last time write locked in file /home/admin/129_20200113173827294_121311408_code/rpm_workspace/storage/innobase/row/row0mysql.cc line 4290
...

It seems that a rw_lock was hold in row0mysql.cc:4290, and we address that dict_operation_lock has been hold by a thread in func row_drop_table_for_mysql --> row_mysql_lock_data_dictionary

However, when we run "thread apply all bt" in the core dump file, we can not find a stack with row_drop_table_for_mysql. It seems like the thread holding lock disappears.

Is it possible? Why can't find the thread holding the lock?
Please let me know. Thx a lot.

How to repeat:
It happened by accident. We have not known how to repeat.

Hi Mr. zjy,

Thank you for your bug report.

I have carefully analysed your bug and it turns out to be duplicate of the following bug:

https://bugs.mysql.com/bug.php?id=91977

I will update the other bug too, in order to influence the scheduling.