MySQL Bugs: #98294: mysqld got signal 6 ;

Bug #98294	mysqld got signal 6 ;
Submitted:	20 Jan 2020 10:37	Modified:	24 Feb 2020 13:53
Reporter:	Nilesh A.	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	MySQL 5.7.28	OS:	Ubuntu (16.04 LTS OS)
Assigned to:		CPU Architecture:	Any

Description:
[ERROR] InnoDB: Page old data size 13093 new data size 13095, page old max ins size 3138 new max ins size 3136
[ERROR] InnoDB: Submit a detailed bug report to http://bugs.mysql.com
0x7feddd255700  InnoDB: Assertion failure in thread 140659594188544 in file btr0cur.cc line 4161

InnoDB: Failing assertion: rec
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.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
10:30:06 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.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=31
max_threads=214
thread_count=15
connection_count=15
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 93231 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7feda82b6d30
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 = 7feddd254e70 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xe8365b]
/usr/sbin/mysqld(handle_fatal_signal+0x489)[0x772af9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7fef3a9e6390]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7fef39d9f428]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fef39da102a]
/usr/sbin/mysqld[0x74818c]
/usr/sbin/mysqld(_Z25btr_cur_optimistic_updatemP9btr_cur_tPPmPP16mem_block_info_tPK5upd_tmP9que_thr_tmP5mtr_t+0x640)[0x10b8400]
/usr/sbin/mysqld[0x101f879]
/usr/sbin/mysqld[0x10243ed]
/usr/sbin/mysqld(_Z7row_updP10upd_node_tP9que_thr_t+0x6b)[0x1025edb]
/usr/sbin/mysqld(_Z12row_upd_stepP9que_thr_t+0x8b)[0x102618b]
/usr/sbin/mysqld[0xfe9245]
/usr/sbin/mysqld(_Z20row_update_for_mysqlPKhP14row_prebuilt_t+0x3f)[0xfed06f]
/usr/sbin/mysqld(_ZN11ha_innobase10update_rowEPKhPh+0x21f)[0xf0168f]
/usr/sbin/mysqld(_ZN7handler13ha_update_rowEPKhPh+0x1ab)[0x7cfbdb]
/usr/sbin/mysqld(_Z12mysql_updateP3THDR4ListI4ItemES4_y15enum_duplicatesPyS6_+0x1859)[0xcc7b79]
/usr/sbin/mysqld(_ZN14Sql_cmd_update23try_single_table_updateEP3THDPb+0x1cc)[0xcc9afc]
/usr/sbin/mysqld(_ZN14Sql_cmd_update7executeEP3THD+0x36)[0xcc9e76]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THDb+0x2457)[0xc3d897]
/usr/sbin/mysqld(_Z11mysql_parseP3THDP12Parser_state+0x40d)[0xc422ad]
/usr/sbin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x10a0)[0xc43450]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x1c7)[0xc44a67]
/usr/sbin/mysqld(handle_connection+0x290)[0xd07950]
/usr/sbin/mysqld(pfs_spawn_thread+0x1b4)[0x11f6364]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7fef3a9dc6ba]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fef39e7141d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7feda820e810): is an invalid pointer
Connection ID (thread ID): 138
Status: NOT_KILLED

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

How to repeat:
We have just installed MySQl 5.7.28 and did few tune-up also imported the big sizes DB..

Later after few days crash recovery started and it's happening on frequent basis now.

Hello Mr. A.,

Thank you for your bug report.

However, we do not have much to go with in order to verify your report. We need the table(s) involved in that UPDATE and the exact UPDATE that caused this assertion. Let me point out to you that this is not a wild crash. This is a controlled assert() by our server in order to prevent the corruption of your data.

We can not conclude much from your report. We can only presume that it could be similar to bug #85208.

Also, can you tell us whether the table in question has any UTF strings stored in the BINARY or BLOB data types ???

We need all the feedback cited above, in order to proceed.

Let us also inform you that this could be just an instant problem with some of your RAM modules. If you are, however, using ECC RAM modules, 2 bits checking 1 bit correcting, that this is not a case.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".