Bug #100193 Mysql Crashed Unexpectedly after complaining out of memory
Submitted: 12 Jul 2020 15:51 Modified: 12 Aug 2020 16:05
Reporter: Sundar Ganesh Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:8.0.14 OS:Red Hat (7.5)
Assigned to: CPU Architecture:x86
Tags: crash, Memory

[12 Jul 2020 15:51] Sundar Ganesh
Description:
MySQL crashed after complaining out of memory. 
Did not find any unusual queries on the server while it crashed. 

Number of connections and threads were within limits configured. 

Providing the backtrace and sample query that caused MySQL to go out of memory and crash.  

We think this could be due a bug. Let me know if any other configuration or additional details that are required for investigating this and I can provide the same. 

The query that cause the MySQL server to crash was of the below format: 

REVOKE SHOW VIEW,SELECT,EXECUTE ON `database_name`.* FROM 'username'@'ipv4_address'; 

--- 

Timestamp:  Thread ID [ERROR] [MY-010934] [Server] Out of memory (Needed 20971552 bytes)
Timestamp:  Thread ID  [ERROR] [MY-010934] [Server] Out of memory (Needed 20971552 bytes)

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

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=33554432
read_buffer_size=131072
max_used_connections=849
max_threads=1000
thread_count=578
connection_count=577
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 433432 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f58600311c0
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 = 7f5a85126c70 thread_stack 0x46000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char*, unsigned long)+0x3d) [0x1cfb26d]
/usr/sbin/mysqld(handle_fatal_signal+0x423) [0xe32c63]
/lib64/libpthread.so.0(+0xf680) [0x7f653675e680]
/lib64/libc.so.6(gsignal+0x37) [0x7f6534a76207]
/lib64/libc.so.6(abort+0x148) [0x7f6534a778f8]
/lib64/libstdc++.so.6(__gnu_cxx::__verbose_terminate_handler()+0x165) [0x7f65353857d5]
/lib64/libstdc++.so.6(+0x5e746) [0x7f6535383746]
/lib64/libstdc++.so.6(+0x5e773) [0x7f6535383773]
/lib64/libstdc++.so.6(+0x5e993) [0x7f6535383993]
/lib64/libstdc++.so.6(operator new(unsigned long)+0x7d) [0x7f6535383f2d]
/usr/sbin/mysqld(std::vector<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_acl_user_t, ACL_USER, boost::property<boost::vertex_name_t, std::string, boost::no_property> >, boost::property<boost::edge_capacity_t, int, boost::no_property>, boost::no_property, boost::listS>, boost::vecS, boost::setS, boost::bidirectionalS, boost::property<boost::vertex_acl_user_t, ACL_USER, boost::property<boost::vertex_name_t, std::string, boos/usr/sbin/mysqld(create_role_vertex(ACL_USER*)+0x235) [0xebff55]
/usr/sbin/mysqld(rebuild_vertex_index(THD*)+0x5f) [0xec006f]
/usr/sbin/mysqld(populate_roles_caches(THD*, TABLE_LIST*)+0x8ac) [0xed801c]
/usr/sbin/mysqld(acl_reload(THD*)+0x32f3) [0xe94623]
/usr/sbin/mysqld(reload_acl_caches(THD*)+0x3c) [0xe9789c]
/usr/sbin/mysqld(log_and_commit_acl_ddl(THD*, bool, std::set<LEX_USER*, std::less<LEX_USER*>, std::allocator<LEX_USER*> >*, bool, bool, bool)+0x79) [0xec3149]
/usr/sbin/mysqld(mysql_grant(THD*, char const*, List<LEX_USER>&, unsigned long, bool, bool, List<MYSQL_LEX_CSTRING> const&, bool)+0x43d) [0xeb8ecd]
/usr/sbin/mysqld(mysql_execute_command(THD*, bool)+0x4172) [0xd1b2b2]
/usr/sbin/mysqld(mysql_parse(THD*, Parser_state*, bool)+0x36b) [0xd1b8db]
/usr/sbin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0x2e9b) [0xd1ebfb]
/usr/sbin/mysqld(do_command(THD*)+0x1a1) [0xd1f6f1]
/usr/sbin/mysqld() [0xe24768]
/usr/sbin/mysqld() [0x21da91f]
/lib64/libpthread.so.0(+0x7dd5) [0x7f6536756dd5]
/lib64/libc.so.6(clone+0x6d) [0x7f6534b3eb3d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (): REVOKE SHOW VIEW,SELECT,EXECUTE ON `database_name`.* FROM 'username'@'ipv4_address'
Connection ID (thread ID): THREAD ID
Status: NOT_KILLED

--- 

How to repeat:
Cannot reproduce the issue. 

Suggested fix:
MySQL recovered from the crash later.
[12 Jul 2020 16:05] MySQL Verification Team
Thank you for the bug report. You are with and older version server, please try the latest version 8.0.20.
[13 Aug 2020 1:00] Bugs System
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".