[MDEV-15567] Signal 11 crash on 10.2.13_18318 Created: 2018-03-14  Updated: 2020-08-25  Resolved: 2018-05-28

Status: Closed
Project: MariaDB Server
Component/s: Stored routines
Affects Version/s: 10.2.13
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Juan Assignee: Unassigned
Resolution: Incomplete Votes: 2
Labels: need_feedback
Environment:

Virtualized RHEL
MariaDB Enterprise 10.2.13_18318


Attachments: Text File MariaDB_Crash.txt    

 Description   

User reported signal 11. Awaiting answers on details from associated support case.
Nothing in the error log for over 3h preceding the signal 11.

180314 23:30:13 [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.2.13-MariaDB-log
key_buffer_size=67108864
read_buffer_size=131072
max_used_connections=39
max_threads=10002
thread_count=27
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 22047175 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x7f81b80bae58
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 = 0x7f83c01dfd70 thread_stack 0x40000
(my_addr_resolve failure: fork)
/usr/sbin/mysqld(my_print_stacktrace+0x2e) [0x55885dc793fe]
/usr/sbin/mysqld(handle_fatal_signal+0x355) [0x55885d70efb5]
/lib64/libpthread.so.0(+0xf5e0) [0x7f98cdb2b5e0]
/usr/sbin/mysqld(+0x570be1) [0x55885d55ebe1]
/usr/sbin/mysqld(plugin_unlock_list(THD*, st_plugin_int**, unsigned int)+0x57) [0x55885d562907]
/usr/sbin/mysqld(lex_end_stage1(LEX*)+0x5e) [0x55885d5363ce]
/usr/sbin/mysqld(lex_end(LEX*)+0x11) [0x55885d536551]
/usr/sbin/mysqld(Sp_handler::db_load_routine(THD*, Database_qualified_name const*, sp_head**, unsigned long long, st_mysql_const_lex_string const&, st_mysql_const_lex_string const&, st_mysql_const_lex_string const&, st_sp_chistics const&, AUTHID const&, long long, long long, sp_package*, Stored_program_creation_ctx*) const+0x21d) [0x55885d8341ed]
/usr/sbin/mysqld(Sp_handler::sp_clone_and_link_routine(THD*, Database_qualified_name const*, sp_head*) const+0x1ea) [0x55885d83681a]
/usr/sbin/mysqld(Sp_handler::sp_find_package_routine(THD*, st_mysql_const_lex_string, Database_qualified_name const*, bool) const+0xed) [0x55885d836a0d]
/usr/sbin/mysqld(Sp_handler_package_procedure::sp_find_routine(THD*, Database_qualified_name const*, bool) const+0xb5) [0x55885d836b25]
/usr/sbin/mysqld(+0x55d86b) [0x55885d54b86b]
/usr/sbin/mysqld(Sql_cmd_call::execute(THD*)+0x90) [0x55885d54c100]
/usr/sbin/mysqld(mysql_execute_command(THD*)+0x14fb) [0x55885d551c0b]
/usr/sbin/mysqld(sp_instr_stmt::exec_core(THD*, unsigned int*)+0x36) [0x55885d4c9a06]
/usr/sbin/mysqld(sp_lex_keeper::reset_lex_and_exec_core(THD*, unsigned int*, bool, sp_instr*)+0x99) [0x55885d4d15c9]
/usr/sbin/mysqld(sp_instr_stmt::execute(THD*, unsigned int*)+0x205) [0x55885d4d1bc5]
/usr/sbin/mysqld(sp_head::execute(THD*, bool)+0x83e) [0x55885d4cd62e]
/usr/sbin/mysqld(sp_head::execute_procedure(THD*, List<Item>*)+0x73d) [0x55885d4ce75d]
/usr/sbin/mysqld(+0x55bbd9) [0x55885d549bd9]
/usr/sbin/mysqld(+0x55d906) [0x55885d54b906]
/usr/sbin/mysqld(Sql_cmd_call::execute(THD*)+0x90) [0x55885d54c100]
/usr/sbin/mysqld(mysql_execute_command(THD*)+0x14fb) [0x55885d551c0b]
/usr/sbin/mysqld(sp_instr_stmt::exec_core(THD*, unsigned int*)+0x36) [0x55885d4c9a06]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f81b98f11c0): PKG_REFERRAL_XXXXX.SP_YYYY( XXXX_CONST('v_cntry',_utf8mb4'SG' COLLATE 'utf8mb4_bin'),  NAME_CONST('p_rid',_utf8'58554' COLLATE 'utf8_general_ci'))
Connection ID (thread ID): 42311
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=on,mrr_cost_based=on,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=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_grouping_derived=on



 Comments   
Comment by Elena Stepanova [ 2018-03-15 ]

Please provide the steps to reproduce or describe the steps you took in attempt to reproduce, and all standard information needed for investigating the problem.

Comment by Adrian Williams [ 2018-03-20 ]

Hi,
I don't want to hijack but i believe i have the same issue.
running 10.2.13 on Centos 7.

This is reproducible by running a query that joins on views when together they exceed the table limit.
The service crashes immediately even when running an explain on the query.
Previously this used to just reject the query with the response of too many tables. MariaDB_Crash.txt

Comment by Elena Stepanova [ 2018-03-21 ]

techforge-Ade, I don't see the relevance. What makes you think it's the same issue?

Comment by Adrian Williams [ 2018-03-22 ]

Hi Elena, i was just going by the signal 11 error and the log details looked similar.
I don't know enough about it to understand the error, i am more than happy to create a new issue if it's not related.

Comment by Elena Stepanova [ 2018-03-22 ]

techforge-Ade, yes, please create a new issue. Thanks.

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