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

[19 Mar 2020 3:09] zanye zjy
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.
[19 Mar 2020 14:12] MySQL Verification Team
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:


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