[MDEV-20041] MariaDB Error Log Content Created: 2019-07-11  Updated: 2019-07-21  Resolved: 2019-07-21

Status: Closed
Project: MariaDB Server
Component/s: Backup, Debug, Replication, Storage Engine - InnoDB
Affects Version/s: 10.0.17
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Gong Seonsik Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: crash, replication

Issue Links:
Relates
relates to MDEV-8106 MariaDB 10.0 and 10.1 crash Closed

 Description   

Server version: 10.0.17-MariaDB-log
key_buffer_size=4370432
read_buffer_size=1048576
max_used_connections=1444
max_threads=2010
thread_count=870
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4203767 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x7f846522e008
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 = 0x7f7e25bfed08 thread_stack 0x40000
mysys/stacktrace.c:247(my_print_stacktrace)[0xbc4eee]
sql/signal_handler.cc:153(handle_fatal_signal)[0x71c4dc]
/lib64/libpthread.so.0[0x3287a0f7e0]
sql/sql_select.cc:1023(JOIN::optimize())[0x5ea7ef]
sql/sql_derived.cc:804(mysql_derived_optimize(THD*, LEX*, TABLE_LIST*))[0x5752bd]
sql/sql_derived.cc:192(mysql_handle_single_derived(LEX*, TABLE_LIST*, unsigned int))[0x574b9a]
sql/table.cc:6915(TABLE_LIST::handle_derived(LEX*, unsigned int))[0x638e6a]
sql/sql_lex.cc:3550(st_select_lex::handle_derived(LEX*, unsigned int))[0x587090]
sql/sql_select.cc:1082(JOIN::optimize_inner())[0x5e7418]
sql/sql_select.cc:1037(JOIN::optimize())[0x5eaa22]
sql/sql_derived.cc:938(mysql_derived_fill(THD*, LEX*, TABLE_LIST*))[0x573e3e]
sql/sql_derived.cc:824(mysql_derived_optimize(THD*, LEX*, TABLE_LIST*))[0x575301]
sql/sql_derived.cc:192(mysql_handle_single_derived(LEX*, TABLE_LIST*, unsigned int))[0x574b9a]
sql/table.cc:6915(TABLE_LIST::handle_derived(LEX*, unsigned int))[0x638e6a]
sql/sql_lex.cc:3550(st_select_lex::handle_derived(LEX*, unsigned int))[0x587090]
sql/sql_select.cc:1082(JOIN::optimize_inner())[0x5e7418]
sql/sql_select.cc:1037(JOIN::optimize())[0x5eaa22]
sql/sql_select.cc:373(handle_select(THD*, LEX*, select_result*, unsigned long))[0x5ee7ed]
sql/sql_parse.cc:5263(execute_sqlcom_select)[0x590240]
sql/sql_parse.cc:2550(mysql_execute_command(THD*))[0x596495]
sql/sp_head.cc:3201(sp_instr_stmt::exec_core(THD*, unsigned int*))[0x84217e]
sql/sp_head.cc:2966(sp_lex_keeper::reset_lex_and_exec_core(THD*, unsigned int*, bool, sp_instr*))[0x84231c]
sql/sp_head.cc:3115(sp_instr_stmt::execute(THD*, unsigned int*))[0x848702]
sql/sp_head.cc:1370(sp_head::execute(THD*, bool))[0x84666c]
sql/sp_head.cc:1910(sp_head::execute_function(THD*, Item*, unsigned int, Field))[0x8493ef]
sql/item_func.cc:6751(Item_func_sp::execute_impl(THD*))[0x783020]
sql/item_func.cc:6684(Item_func_sp::execute())[0x784373]
sql/item_func.h:2073(Item_func_sp::val_int())[0x791721]
sql/item.cc:6482(Item::send(Protocol*, String*))[0x730a81]
sql/protocol.cc:904(Protocol::send_result_set_row(List<Item>*))[0x514942]
sql/sql_class.cc:2542(select_send::send_data(List<Item>&))[0x56375c]
sql/sql_select.cc:2454(JOIN::exec_inner())[0x5ecb50]
sql/sql_select.cc:2372(JOIN::exec())[0x5eabba]
sql/sql_select.cc:373(handle_select(THD*, LEX*, select_result*, unsigned long))[0x5ee7ed]
sql/sql_parse.cc:5263(execute_sqlcom_select)[0x590240]
sql/sql_parse.cc:2550(mysql_execute_command(THD*))[0x596495]
sql/sql_parse.cc:6517(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x59d8ea]
sql/sql_parse.cc:1302(dispatch_command(enum_server_command, THD*, char*, unsigned int))[0x59f757]
sql/sql_parse.cc:996(do_command(THD*))[0x59fe68]
sql/threadpool_common.cc:233(threadpool_process_request(THD*))[0x6b38e8]
sql/threadpool_unix.cc:1448(handle_event)[0x6eff98]
/lib64/libpthread.so.0[0x3287a07aa1]
/lib64/libc.so.6(clone+0x6d)[0x32876e893d]

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

 Comments   
Comment by Alice Sherepa [ 2019-07-11 ]

Is it suitable for you to upgrade to the recent version of MariaDB (for 10.0 it is 10.0.38) and see if the crash is still present there? A lot of bugs were fixed since 10.0.17

Comment by Gong Seonsik [ 2019-07-12 ]

I did not upgrade.
I just want to know the cause of the error. Please let me know why. then Thank You.

Comment by Alice Sherepa [ 2019-07-12 ]

Is that crash repeatable for you or did it happen only once?
Maybe you know the query, that is causing the crash?
It would be perfect if you could provide a test case to demonstrate the problem.

Comment by Gong Seonsik [ 2019-07-15 ]

The collision was not repetitive.
And I could not figure out which query was causing the crash.
I don't know, but there was a replication crash due to innodb crash.

Comment by Elena Stepanova [ 2019-07-21 ]

10.0 release line is not supported any longer. Also, the last 10.0 release was 10.0.38, which is 20 releases and almost 4 years ahead of the one you are using. There had been numerous bugfixes since 2015, including the area which your stack trace points at. Without a test case, it is impossible to say which exactly bug you have encountered, and whether it has been fixed. Please upgrade to the latest release of a supported release line (10.1, 10.2, 10.3, 10.4).

Generated at Thu Feb 08 08:56:16 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.