Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Cannot Reproduce
-
10.1.16
-
None
Description
A customer has reported a crash on a Galera node:
161113 1:30:29 [ERROR] mysqld got signal 11 ;
|
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.
|
|
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
|
|
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.
|
|
Server version: 10.1.16-MariaDB
|
key_buffer_size=16777216
|
read_buffer_size=262144
|
max_used_connections=561
|
max_threads=1002
|
thread_count=40
|
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 806424 K bytes of memory
|
Hope that's ok; if not, decrease some variables in the equation.
|
|
Thread pointer: 0x0x7ff4146c4008
|
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 = 0x7ff20228c208 thread_stack 0x48400
|
(my_addr_resolve failure: fork)
|
/<redacted>/bin/mysqld(my_print_stacktrace+0x2e) [0xc099ee]
|
/<redacted>/bin/mysqld(handle_fatal_signal+0x4ba) [0x7664da]
|
/lib64/libpthread.so.0() [0x3fe2a0f7e0]
|
/<redacted>/bin/mysqld(MYSQL_BIN_LOG::trx_group_commit_leader(MYSQL_BIN_LOG::group_commit_entry*)+0x639) [0x843a59]
|
/<redacted>/bin/mysqld(MYSQL_BIN_LOG::write_transaction_to_binlog_events(MYSQL_BIN_LOG::group_commit_entry*)+0x1c1) [0x844081]
|
/<redacted>/bin/mysqld(MYSQL_BIN_LOG::write_transaction_to_binlog(THD*, binlog_cache_mngr*, Log_event*, bool, bool, bool)+0x191) [0x8444b1]
|
/<redacted>/bin/mysqld() [0x844549]
|
/<redacted>/bin/mysqld(MYSQL_BIN_LOG::log_and_order(THD*, unsigned long long, bool, bool, bool)+0xa7) [0x844847]
|
/<redacted>/bin/mysqld(ha_commit_trans(THD*, bool)+0x376) [0x76d356]
|
/<redacted>/bin/mysqld(trans_commit_stmt(THD*)+0x2b) [0x69dd2b]
|
/<redacted>/bin/mysqld(mysql_execute_command(THD*)+0xea5) [0x5b2445]
|
/<redacted>/bin/mysqld(mysql_parse(THD*, char*, unsigned int, Parser_state*)+0x2b4) [0x5baeb4]
|
/<redacted>/bin/mysqld() [0x5baf48]
|
/<redacted>/bin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x14e5) [0x5bd025]
|
/<redacted>/bin/mysqld(do_command(THD*)+0x2a7) [0x5be2f7]
|
/<redacted>/bin/mysqld(do_handle_one_connection(THD*)+0x183) [0x68d423]
|
/<redacted>/bin/mysqld(handle_one_connection+0x42) [0x68d642]
|
/lib64/libpthread.so.0() [0x3fe2a07aa1]
|
/lib64/libc.so.6(clone+0x6d) [0x3fe22e8aad]
|
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0x7ff440561020): INSERT INTO <** redacted 65+KB INSERT statement **>
|
|
Connection ID (thread ID): 3622613
|
Status: NOT_KILLED
|
|
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,deri
|
ved_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join
|
_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=off
|
|
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.
|
161113 01:30:29 mysqld_safe Number of processes running now: 0
|
161113 01:30:29 mysqld_safe WSREP: not restarting wsrep node automatically
|
161113 01:30:29 mysqld_safe mysqld from pid file /<redacted>/logs/mariadb.pid ended
|
|
This crash has only happened once, during normal operations. There didn't seem to be anything special going on. The node was able to be brought back into the cluster without a problem.