MySQL Bugs: #98594: Assertion failure: dict0dict.cc

Bug #98594	Assertion failure: dict0dict.cc
Submitted:	14 Feb 2020 8:52	Modified:	16 Mar 2020 13:21
Reporter:	Gabriel Rolland	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	8.0.19	OS:	Windows (Server 2012 R2)
Assigned to:		CPU Architecture:	Any
Tags:	assertion failure, crash, dict0dict.cc, innodb

Description:
From yesterday we got this error.

Timestamp, Thread, Type, Details
2020-02-13T10:24:12, 0, [System] [MY-010931] [Server], C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqld.exe: ready for connections. Version: '8.0.18'  socket: ''  port: 33706  MySQL Community Server - GPL.
2020-02-13T10:24:12, 0, [System] [MY-011323] [Server], X Plugin ready for connections. Bind-address: '::' port: 33060
2020-02-13T10:26:45, 8, [Warning] [MY-010055] [Server], IP address '45.143.220.172' could not be resolved: Host sconosciuto.
2020-02-13T11:45:29, 13, [ERROR] [MY-013183] [InnoDB], Assertion failure: dict0dict.cc:1224:table2 == NULL thread 4824
, , , 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/8.0/en/forcing-innodb-recovery.html
, , , InnoDB: about forcing recovery.
, , , 11:45:29 UTC - mysqld got exception 0x80000003 ;
, , , Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
, , , Thread pointer: 0xe82f23cbf0
, , , 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...
, , , 7ff748b26622    mysqld.exe!?my_errno@@YAHXZ()
, , , 7ffa1b7ad167    ucrtbase.DLL!raise()
, , , 7ffa1b7adff1    ucrtbase.DLL!abort()
, , , 7ff748d0fdec    mysqld.exe!?strncpyz@Event_reader@binary_log@@QEAAXPEAD_K1@Z()
, , , 7ff748cd6063    mysqld.exe!?strncpyz@Event_reader@binary_log@@QEAAXPEAD_K1@Z()
, , , 7ff748d8d6c8    mysqld.exe!?strncpyz@Event_reader@binary_log@@QEAAXPEAD_K1@Z()
, , , 7ff748d8c052    mysqld.exe!?strncpyz@Event_reader@binary_log@@QEAAXPEAD_K1@Z()
, , , 7ff748becaef    mysqld.exe!?strncpyz@Event_reader@binary_log@@QEAAXPEAD_K1@Z()
, , , 7ff747cd834a    mysqld.exe!?ha_open@handler@@QEAAHPEAUTABLE@@PEBDHHPEBVTable@dd@@@Z()
, , , 7ff747d7042f    mysqld.exe!?open_table_from_share@@YAHPEAVTHD@@PEAUTABLE_SHARE@@PEBDIIIPEAUTABLE@@_NPEBVTable@dd@@@Z()
, , , 7ff747e8e41b    mysqld.exe!?open_table@@YA_NPEAVTHD@@PEAUTABLE_LIST@@PEAVOpen_table_context@@@Z()
, , , 7ff747e8d128    mysqld.exe!?open_and_lock_tables@@YA_NPEAVTHD@@PEAUTABLE_LIST@@IPEAVPrelocking_strategy@@@Z()
, , , 7ff747e8f3d9    mysqld.exe!?open_tables@@YA_NPEAVTHD@@PEAPEAUTABLE_LIST@@PEAIIPEAVPrelocking_strategy@@@Z()
, , , 7ff747e8f871    mysqld.exe!?open_tables_for_query@@YA_NPEAVTHD@@PEAUTABLE_LIST@@I@Z()
, , , 7ff747f4a4c2    mysqld.exe!?prepare@Sql_cmd_dml@@UEAA_NPEAVTHD@@@Z()
, , , 7ff747f46b3d    mysqld.exe!?execute@Sql_cmd_dml@@UEAA_NPEAVTHD@@@Z()
, , , 7ff747e9d36a    mysqld.exe!?mysql_execute_command@@YAHPEAVTHD@@_N@Z()
, , , 7ff747e9dfa4    mysqld.exe!?mysql_parse@@YAXPEAVTHD@@PEAVParser_state@@@Z()
, , , 7ff747e9713b    mysqld.exe!?dispatch_command@@YA_NPEAVTHD@@PEBTCOM_DATA@@W4enum_server_command@@@Z()
, , , 7ff747e9818e    mysqld.exe!?do_command@@YA_NPEAVTHD@@@Z()
, , , 7ff747ce1438    mysqld.exe!?modify_thread_cache_size@Per_thread_connection_handler@@SAXK@Z()
, , , 7ff748ee1661    mysqld.exe!?strncpyz@Event_reader@binary_log@@QEAAXPEAD_K1@Z()
, , , 7ff748b265bc    mysqld.exe!?my_thread_join@@YAHPEAUmy_thread_handle@@PEAPEAX@Z()
, , , 7ffa1b75f4a0    ucrtbase.DLL!_o__realloc_base()
, , , 7ffa2a5c13d2    KERNEL32.DLL!BaseThreadInitThunk()
, , , 7ffa2c9e54f4    ntdll.dll!RtlUserThreadStart()
, , , Trying to get some variables.
, , , Some pointers may be invalid and cause the dump to abort.
, , , Query (e82f60f048): SELECT * FROM Z_ACCESSI a1  WHERE  a1.IdUtente = 6 ORDER BY a1.DataOraAccesso
, , , Connection ID (thread ID): 13
, , , 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:
I do not know

Hi Mr. Rolland,

Thank you for your bug report.

Let me inform you, first of all, that what you have got is an intentional assert() call from the InnoDB Storage Engine.

There are several possibilities on why you could get this assert.  I will inform you about the most common ones, based on your output.

1. Your thread_stack is too small

2. You had a very short glitch in your RAM

3. Some of your RAM module is faulty.

4. You have hit a bug in our code

First cause is easy to mend, just increase thread_stack to some higher value, for example 30 % higher than the current one.

Second cause is the most frequent cause of those asserts. If you have ECC RAM, 2 bits checking 1 bit correcting, then you can forget about this possibility. If you do not have those RAM modules, consider installing them. These glitches appear once in a while and always in other locations.They can not be caught and the only remedy is the usage of the ECC RAM.

Third cause is easy to check as there is testing software that diagnosis this kind of problems.

In the case that it is our bug, then you will keep getting these asserts, each one identical as the one you reported here. If that case we need a repeatable test case, so that we can repeat a problem and fix a bug.

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".

Since the update to version 8.0.19 the problem has no longer occurred

Thanks a lot, Mr. Rolland.