MySQL Bugs: #90694: Server crashes

Bug #90694	Server crashes
Submitted:	30 Apr 2018 17:18	Modified:	3 Jul 2018 15:12
Reporter:	ozz Project	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	8.0.11	OS:	Windows
Assigned to:		CPU Architecture:	Other (x64)
Tags:	8.0.11

Description:
The Server was upgraded from 5.7 to version 8.0.11.
The Upgrade runs smooth. Later the server runs but crashes after a certain time.
It seem, that it crashes when innodb reach his maximum memory.

Errorlog below

2018-04-26T21:02:23.283946Z 13 [ERROR] [MY-000000] [InnoDB] InnoDB: Assertion failure: row0sel.cc:4603
InnoDB: thread 2076
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.
21:02:23 UTC - mysqld got exception 0x80000003 ;
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=33554432
read_buffer_size=131072
max_used_connections=4
max_threads=300
thread_count=5
connection_count=4
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 150958 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x320e06cf0
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...
13fdea6d2    mysqld.exe!?my_errno@@YAHXZ()
7fef2f38ba8    ucrtbase.DLL!raise()
7fef2f39921    ucrtbase.DLL!abort()
140036a67    mysqld.exe!??1?$lock_guard@Vmutex@std@@@std@@QEAA@XZ()
1400dee08    mysqld.exe!??1?$lock_guard@Vmutex@std@@@std@@QEAA@XZ()
13ff282ab    mysqld.exe!??1?$lock_guard@Vmutex@std@@@std@@QEAA@XZ()
13f0afa64    mysqld.exe!?ha_index_next_same@handler@@QEAAHPEAEPEBEI@Z()
13f40baf8    mysqld.exe!?join_read_last_key@@YAHPEAVQEP_TAB@@@Z()
13f40f750    mysqld.exe!?sub_select@@YA?AW4enum_nested_loop_state@@PEAVJOIN@@PEAVQEP_TAB@@_N@Z()
13f40a08d    mysqld.exe!?erase@?$_Hash@V?$_Uset_traits@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$_Uhash_compare@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@U?$hash@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@U?$equal_to@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@2@V?$Memroot_allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@@$0A@@std@@@std@@QEAA?AV?$_List_const_iterator@V?$_List_val@U?$_List_simple_types@V?$basic_string@DU?
13f40f7ed    mysqld.exe!?sub_select@@YA?AW4enum_nested_loop_state@@PEAVJOIN@@PEAVQEP_TAB@@_N@Z()
13f40a08d    mysqld.exe!?erase@?$_Hash@V?$_Uset_traits@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$_Uhash_compare@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@U?$hash@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@U?$equal_to@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@2@V?$Memroot_allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@@$0A@@std@@@std@@QEAA?AV?$_List_const_iterator@V?$_List_val@U?$_List_simple_types@V?$basic_string@DU?
13f40f7ed    mysqld.exe!?sub_select@@YA?AW4enum_nested_loop_state@@PEAVJOIN@@PEAVQEP_TAB@@_N@Z()
13f408499    mysqld.exe!?create_intermediate_table@JOIN@@AEAA_NPEAVQEP_TAB@@PEAV?$List@VItem@@@@AEAVORDER_with_src@@_N@Z()
13f40a7d7    mysqld.exe!?exec@JOIN@@QEAAXXZ()
13f319256    mysqld.exe!?handle_query@@YA_NPEAVTHD@@PEAULEX@@PEAVQuery_result@@_K3@Z()
13f23c252    mysqld.exe!?execute_show@@YA_NPEAVTHD@@PEAUTABLE_LIST@@@Z()
13f23e537    mysqld.exe!?mysql_execute_command@@YAHPEAVTHD@@_N@Z()
13f2412d6    mysqld.exe!?mysql_parse@@YAXPEAVTHD@@PEAVParser_state@@@Z()
13f23ad98    mysqld.exe!?dispatch_command@@YA_NPEAVTHD@@PEBTCOM_DATA@@W4enum_server_command@@@Z()
13f23bcc5    mysqld.exe!?do_command@@YA_NPEAVTHD@@@Z()
13f0cd068    mysqld.exe!?pop_front@?$list@PEAVChannel_info@@V?$allocator@PEAVChannel_info@@@std@@@std@@QEAAXXZ()
1401ce347    mysqld.exe!??1?$lock_guard@Vmutex@std@@@std@@QEAA@XZ()
13fdea66c    mysqld.exe!?my_thread_join@@YAHPEAUmy_thread_handle@@PEAPEAX@Z()
7fef2f3be5d    ucrtbase.DLL!_crt_at_quick_exit()
77a859cd    kernel32.dll!BaseThreadInitThunk()
77be383d    ntdll.dll!RtlUserThreadStart()

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (32103d488): show table status like 'hitcounter'
Connection ID (thread ID): 13
Status: NOT_KILLED

How to repeat:
try to reach the innodb memory limit (innodb-buffer-pool-size)

Hi,

Thank you for your bug report.

However, we can not do much with the info that you have sent us. We do not yet have any report similar to yours. Hence, we require full test case, with all tables involved and the SELECT query that produces the assert.  For your easier search, that query contains the nested queries.  This is not a crash, but an assert. Query that produces the assert is not the one in the report, but the one that we described here.

Hello!

I have a similar problem on Centos 6

2018-05-22T07:10:09.960583Z 61 [ERROR] [MY-000000] [InnoDB] InnoDB: Assertion failure: row0sel.cc:4603
InnoDB: thread 140117005891328
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.
07:10:09 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=9
max_threads=151
thread_count=4
connection_count=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 67841 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f6f34138420
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 = 7f6f885cec60 thread_stack 0x46000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char*, unsigned long)+0x2e) [0x1a0b76e]
/usr/sbin/mysqld(handle_fatal_signal+0x413) [0xcd0a33]
/lib64/libpthread.so.0(+0xf7e0) [0x7f6fc35a77e0]
/lib64/libc.so.6(gsignal+0x35) [0x7f6fc19f6495]
/lib64/libc.so.6(abort+0x175) [0x7f6fc19f7c75]
/usr/sbin/mysqld() [0xac76d6]
/usr/sbin/mysqld(row_search_mvcc(unsigned char*, page_cur_mode_t, row_prebuilt_t*, unsigned long, unsigned long)+0x31d8) [0x1c082c8]
/usr/sbin/mysqld(ha_innobase::general_fetch(unsigned char*, unsigned int, unsigned int)+0xb0) [0x1ad5110]
/usr/sbin/mysqld(handler::ha_index_next(unsigned char*)+0x1cf) [0xdbd22f]
/usr/sbin/mysqld() [0xb982bc]
/usr/sbin/mysqld(sub_select(JOIN*, QEP_TAB*, bool)+0x2c7) [0xb9fa37]
/usr/sbin/mysqld(JOIN::exec()+0x3f0) [0xb9e820]
/usr/sbin/mysqld(handle_query(THD*, LEX*, Query_result*, unsigned long long, unsigned long long)+0x278) [0xc11aa8]
/usr/sbin/mysqld(execute_show(THD*, TABLE_LIST*)+0x298) [0xbc7ea8]
/usr/sbin/mysqld(mysql_execute_command(THD*, bool)+0x4ba3) [0xbd12d3]
/usr/sbin/mysqld(mysql_parse(THD*, Parser_state*)+0x30f) [0xbd24bf]
/usr/sbin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0x2ca7) [0xbd53c7]
/usr/sbin/mysqld(do_command(THD*)+0x1a1) [0xbd5e91]
/usr/sbin/mysqld() [0xcc3b60]
/usr/sbin/mysqld() [0x1e8641f]
/lib64/libpthread.so.0(+0x7aa1) [0x7f6fc359faa1]
/lib64/libc.so.6(clone+0x6d) [0x7f6fc1aacbcd]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f6f341575a8): is an invalid pointer
Connection ID (thread ID): 61
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.

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

May be related to #91118.
@ozz Project, do you have MEMORY tables?

no, i do not use MEMORY Tables.

Hi,

Once again, we can not locate the bug with what you have sent us. We do not yet have any report similar to these two . Hence, we require full test case, with all tables involved and the SELECT (or SHOW) query that produces the assert.  Also, this is not a crash, but an assert.

We are waiting for further info from you, so that we could repeat it.