Bug #97911 [FATAL] Semaphore wait has lasted > 600 seconds. We intentionally crash the serv
Submitted: 6 Dec 2019 9:20 Modified: 9 Dec 2019 13:11
Reporter: NOT_FOUND NULL ! Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:8.0.17 OS:CentOS (64G RAM)
Assigned to: CPU Architecture:x86 (Intel(R) Xeon(R) CPU E5-2665 0 @ 2.40GHz)
Tags: intentionally crash the server because it appears to be hung

[6 Dec 2019 9:20] NOT_FOUND NULL !
Description:
Dec  5 23:00:00 dromdal01 mysqld: InnoDB: ###### Diagnostic info printed to the standard error stream
Dec  5 23:00:00 dromdal01 mysqld: 2019-12-05T23:00:00.609147Z 0 [ERROR] [MY-012872] [InnoDB] Semaphore wait has lasted > 39052544 seconds. We intentionally crash the server because it appears to be hung.[FATAL] Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung.
Dec  5 23:00:00 dromdal01 mysqld: 2019-12-05T23:00:00.609195Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: ut0ut.cc:539 thread 140305944786688
Dec  5 23:00:00 dromdal01 mysqld: InnoDB: We intentionally generate a memory trap.
Dec  5 23:00:00 dromdal01 mysqld: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
Dec  5 23:00:00 dromdal01 mysqld: InnoDB: If you get repeated assertion failures or crashes, even
Dec  5 23:00:00 dromdal01 mysqld: InnoDB: immediately after the mysqld startup, there may be
Dec  5 23:00:00 dromdal01 mysqld: InnoDB: corruption in the InnoDB tablespace. Please refer to
Dec  5 23:00:00 dromdal01 mysqld: InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
Dec  5 23:00:00 dromdal01 mysqld: InnoDB: about forcing recovery.
Dec  5 23:00:00 dromdal01 mysqld: 23:00:00 UTC - mysqld got signal 6 ;
Dec  5 23:00:00 dromdal01 mysqld: Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Dec  5 23:00:00 dromdal01 mysqld: Thread pointer: 0x0
Dec  5 23:00:00 dromdal01 mysqld: Attempting backtrace. You can use the following information to find out
Dec  5 23:00:00 dromdal01 mysqld: where mysqld died. If you see no messages after this, something went
Dec  5 23:00:00 dromdal01 mysqld: terribly wrong...
Dec  5 23:00:00 dromdal01 mysqld: stack_bottom = 0 thread_stack 0x46000
Dec  5 23:00:00 dromdal01 mysqld: /usr/sbin/mysqld(my_print_stacktrace(unsigned char*, unsigned long)+0x3d) [0x1e435bd]
Dec  5 23:00:00 dromdal01 mysqld: /usr/sbin/mysqld(handle_fatal_signal+0x333) [0xf25e83]
Dec  5 23:00:00 dromdal01 mysqld: /lib64/libpthread.so.0(+0xf5f0) [0x7f9bea7175f0]
Dec  5 23:00:00 dromdal01 mysqld: /lib64/libc.so.6(gsignal+0x37) [0x7f9be8a2c337]
Dec  5 23:00:00 dromdal01 mysqld: /lib64/libc.so.6(abort+0x148) [0x7f9be8a2da28]
Dec  5 23:00:00 dromdal01 mysqld: /usr/sbin/mysqld() [0xca40da]
Dec  5 23:00:00 dromdal01 mysqld: /usr/sbin/mysqld(ib::fatal::~fatal()+0x129) [0x20e4769]
Dec  5 23:00:00 dromdal01 mysqld: /usr/sbin/mysqld(srv_error_monitor_thread()+0x740) [0x20887e0]
Dec  5 23:00:00 dromdal01 mysqld: /usr/sbin/mysqld(std::thread::_State_impl<std::thread::_Invoker<std::tuple<Runnable, void (*)()> > >::_M_run()+0xb5) [0x1eeb725]
Dec  5 23:00:00 dromdal01 mysqld: /usr/sbin/mysqld() [0x253aa9f]
Dec  5 23:00:00 dromdal01 mysqld: /lib64/libpthread.so.0(+0x7e65) [0x7f9bea70fe65]
Dec  5 23:00:00 dromdal01 mysqld: /lib64/libc.so.6(clone+0x6d) [0x7f9be8af488d]
Dec  5 23:00:00 dromdal01 mysqld: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
Dec  5 23:00:00 dromdal01 mysqld: information that should help you find out what is causing the crash.
Dec  5 23:01:08 dromdal01 mysqld: 2019-12-05T23:00:02.006813Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.17) starting as process 17238
Dec  5 23:01:28 dromdal01 mysqld: InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 712019-12-05T23:01:26.664884Z 0 [System] [MY-010229] [Server] Starting crash recovery...
Dec  5 23:01:28 dromdal01 mysqld: 2019-12-05T23:01:26.675106Z 0 [System] [MY-010232] [Server] Crash recovery finished.
Dec  5 23:01:28 dromdal01 mysqld: 2019-12-05T23:01:28.363661Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.17'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server - GPL.

How to repeat:
I can't repeat it just happen rare and random

Suggested fix:
No
[6 Dec 2019 9:22] NOT_FOUND NULL !
mysqld.log

Attachment: mysqld.log (application/octet-stream, text), 688.66 KiB.

[6 Dec 2019 9:27] NOT_FOUND NULL !
I says that 

Semaphore wait has lasted > 39052544 seconds

which is impossible due that is 451 days, 23 hours, 55 minutes and 44 seconds.

and 8.0.17 was not available 451 days ago
[9 Dec 2019 9:18] MySQL Verification Team
https://bugs.mysql.com/bug.php?id=88523
[9 Dec 2019 13:11] MySQL Verification Team
Hello Mr. NULL,

Thank you for your bug report.

This bug is a duplicate of the original bug:

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

There are many duplicates of that bug and nobody of the reporters has provided us with a fully repeatable test case, that would enable us to run it and see the same behaviour that you have reported.

If you are capable of providing us with a fully repeatable test case, we would be grateful. This test case should consist of the sequence of SQL statements, which would lead to the behaviour that you describe.

Regarding a very long semaphore wait, that is easy to explain. It is a monitor thread, hence if you have that uptime, this is quite feasible. 

Anyway, the only way to proceed is to have a fully repeatable test case, as described above.