InnoDB: Error: semaphore wait has lasted > 600 seconds -- srv0srv.cc line 2192

Description

one of a server i manage, crashed .

 

What do you think ?

 

 

{{}}InnoDB: ###### Diagnostic info printed to the standard error stream
InnoDB: Error: semaphore wait has lasted > 600 seconds
InnoDB: We intentionally crash the server, because it appears to be hung.
2019-01-09 02:43:36 7e9cb9a55700 InnoDB: Assertion failure in thread 139211594618624 in file srv0srv.cc line 2192
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
07:43:36 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/key_buffer_size=34359738368
read_buffer_size=262144
max_used_connections=53
max_threads=8002
thread_count=46
connection_count=44
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 37762907 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2c)[0x55fe7e3d785c]
/usr/sbin/mysqld(handle_fatal_signal+0x481)[0x55fe7e1608d1]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7f712b6d70c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7f7129542fff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f712954442a]
/usr/sbin/mysqld(+0x7d622d)[0x55fe7e50222d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7494)[0x7f712b6cd494]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f71295f8acf]
You may download the Percona Server operations manual by visiting
http://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.

 

Environment

None

Attachments

1

Smart Checklist

Activity

Show:

Kathy Williamson April 22, 2020 at 4:27 PM

MySQL 5.6 is scheduled for EOL in Feb 2021.  At this time, we do not believe that this issue will be fixed prior to EOL.  If you believe this issue is important enough to be be fixed prior to EOL, or that it also affects a later version, please leave a comment and we will consider the new information

Satya Bodapati April 3, 2019 at 8:54 AM

Removed the 'duplicate link of PS-3410'

 

Satya Bodapati April 3, 2019 at 8:50 AM

This should not be duplicate of .  Not all semaphore crashes are same. In this bug, there is long wait table->stats_latch. In , it is about index->lock.

Also in : there is long running ALTER + concurrent DMLs.

In this case, there is I_S query + concurrent Delete that causes the crash.

Please remove the duplicate link and try to reproduce this.

 

Lalit Choudhary February 14, 2019 at 11:54 AM

Lalit Choudhary January 15, 2019 at 1:17 PM

Hello

Thank you for the report.

Please share my.cnf and MySQL error file for the time of the crash. 

Output of

Size of the table approximately?

If you have reproduced test case please provide that too.

Similar issue reported in 5.7 version of percona server and MySQL community version.

https://jira.percona.com/browse/PS-3410

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

Won't Do

Details

Assignee

Reporter

Affects versions

Priority

Smart Checklist

Created January 9, 2019 at 6:42 PM
Updated March 6, 2024 at 12:25 PM
Resolved April 22, 2020 at 4:27 PM