[MDEV-30285] Failed to execute ALTER EVENT Created: 2022-12-21  Updated: 2022-12-21  Resolved: 2022-12-21

Status: Closed
Project: MariaDB Server
Component/s: Events
Affects Version/s: 10.5.16
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: guozhentang Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: crash
Environment:

centos 7.6


Issue Links:
Duplicate
duplicates MDEV-24686 SIGSEGV's in __memmove_avx_unaligned_... Confirmed

 Description   

The specific execution steps are as follows:

create database ALTER_EVENT_145;
show databases like 'ALTER_EVENT_145';
use ALTER_EVENT_145;
create table ALTER_EVENT_145(time TIMESTAMP);
show tables like 'ALTER_EVENT_145';
create event ALTER_EVENT_145 on schedule every 5 second do insert into ALTER_EVENT_145 values(now());
select EVENT_SCHEMA,EVENT_NAME,EVENT_DEFINITION,INTERVAL_VALUE,INTERVAL_FIELD,STATUS,ON_COMPLETION,EVENT_COMMENT from information_schema.events where EVENT_NAME='ALTER_EVENT_145' and EVENT_SCHEMA='ALTER_EVENT_145';
set @@global.event_scheduler=ON;
show variables like 'event_scheduler';
Alter definer='root'@'localhost' event ALTER_EVENT_145 on schedule at current_timestamp + interval '2-10' year_month on completion not preserve rename to a disable on slave;

error log

221214 23:20:02 [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.5.16-221000-MariaDB-log
key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=68
max_threads=2002
thread_count=56
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4676969 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x7f30ec001198
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 = 0x7f3210499de8 thread_stack 0x49000
mysys/stacktrace.c:213(my_print_stacktrace)[0x55b350413c2e]
sql/signal_handler.cc:225(handle_fatal_signal)[0x55b34fe6ed25]
??:0(funlockfile)[0x7f32b03d85a0]
strings/strcoll.inl:99(my_scan_weight_utf8mb3_general_ci)[0x55b350460113]
sql/event_data_objects.cc:1614(event_basic_identifier_equal(st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, Event_basic*))[0x55b34fd4adea]
sql/event_queue.cc:427(Event_queue::find_n_remove_event(st_mysql_const_lex_string const*, st_mysql_const_lex_string const*))[0x55b34fffec23]
sql/event_queue.cc:275(Event_queue::update_event(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, Event_queue_element*))[0x55b34ffff08a]
sql/events.cc:555(Events::update_event(THD*, Event_parse_data*, st_mysql_const_lex_string*, st_mysql_const_lex_string*))[0x55b34fd4c039]
sql/sql_parse.cc:5328(mysql_execute_command(THD*))[0x55b34fc67371]
sql/sql_parse.cc:8175(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x55b34fc679aa]
sql/sql_parse.cc:1893(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x55b34fc692eb]
sql/sql_parse.cc:1377(do_command(THD*))[0x55b34fc6ae33]
sql/sql_connect.cc:1419(do_handle_one_connection(CONNECT*, bool))[0x55b34fd66861]
sql/sql_connect.cc:1313(handle_one_connection)[0x55b34fd66ced]
perfschema/pfs.cc:2204(pfs_spawn_thread)[0x55b3500ee9ab]
??:0(__libpthread_freeres)[0x7f32b03cdf3b]
??:0(clone)[0x7f32b0305840]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f30ec033860): Alter definer='root'@'localhost' event ALTER_EVENT_145 on schedule at current_timestamp + interval '2-10' year_month on completion not preserve rename to a disable on slave
 
Connection ID (thread ID): 1726
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=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off
 
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /data/Ruby/data
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units
Max cpu time              unlimited            unlimited            seconds
Max file size             unlimited            unlimited            bytes
Max data size             unlimited            unlimited            bytes
Max stack size            8388608              unlimited            bytes
Max core file size        unlimited            unlimited            bytes
Max resident set          unlimited            unlimited            bytes
Max processes             126424               126424               processes
Max open files            65535                65535                files
Max locked memory         67108864             67108864             bytes
Max address space         unlimited            unlimited            bytes
Max file locks            unlimited            unlimited            locks
Max pending signals       126424               126424               signals
Max msgqueue size         819200               819200               bytes
Max nice priority         0                    0
Max realtime priority     0                    0
Max realtime timeout      unlimited            unlimited            us
Core pattern: /core/core-%e-%u-%s-%t-%h
 
core :
(gdb) bt
#0  0x00007f32b03d5281 in pthread_kill () from /usr/lib64/libpthread.so.0
#1  0x000055b350413a29 in my_write_core (sig=<optimized out>) at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/mysys/stacktrace.c:424
#2  0x000055b34fe6ed40 in handle_fatal_signal (sig=11) at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/sql/signal_handler.cc:344
#3  <signal handler called>
#4  my_scan_weight_utf8mb3_general_ci (end=0xa8 <error: Cannot access memory at address 0xa8>, str=0x0, weight=<synthetic pointer>) at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/strings/strcoll.inl:99
#5  my_scan_weight_utf8mb3_general_ci (end=0xa8 <error: Cannot access memory at address 0xa8>, str=0x0, weight=<synthetic pointer>) at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/strings/strcoll.inl:90
#6  my_strnncollsp_utf8mb3_general_ci (cs=<optimized out>, a=0x7f30ec033e30 "ALTER_EVENT_145", a_length=<optimized out>, b=0x0, b_length=<optimized out>)
    at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/strings/strcoll.inl:256
#7  0x000055b34fd4adea in event_basic_identifier_equal (db=db@entry=0x7f30ec033ad0, name=name@entry=0x7f30ec033ae0, b=b@entry=0x7f30bc021f40) at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/sql/event_data_objects.cc:1614
#8  0x000055b34fffec23 in Event_queue::find_n_remove_event (this=this@entry=0x55b35463b910, db=db@entry=0x7f30ec033ad0, name=name@entry=0x7f30ec033ae0)
    at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/sql/event_queue.cc:427
#9  0x000055b34ffff08a in Event_queue::update_event (this=0x55b35463b910, thd=0x7f30ec001198, dbname=0x7f30ec033ad0, name=0x7f30ec033ae0, new_element=0x0)
    at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/sql/event_queue.cc:265
#10 0x000055b34fd4c039 in Events::update_event (thd=thd@entry=0x7f30ec001198, parse_data=0x7f30ec033ab8, new_dbname=<optimized out>, new_name=<optimized out>)
    at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/sql/events.cc:551
#11 0x000055b34fc67371 in mysql_execute_command (thd=0x7f30ec001198) at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/sql/sql_parse.cc:5328
#12 0x000055b34fc679aa in mysql_parse (thd=thd@entry=0x7f30ec001198, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x7f3210499510, is_com_multi=is_com_multi@entry=false, 
    is_next_command=is_next_command@entry=false) at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/sql/sql_parse.cc:8174
#13 0x000055b34fc692eb in dispatch_command (command=COM_QUERY, thd=0x7f30ec001198, packet=<optimized out>, packet_length=<optimized out>, is_com_multi=<optimized out>, is_next_command=<optimized out>)
    at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/sql/sql_class.h:1290
#14 0x000055b34fc6ae33 in do_command (thd=0x7f30ec001198) at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/sql/sql_parse.cc:1377
#15 0x000055b34fd66861 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55b35464d698, put_in_cache=put_in_cache@entry=true) at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/sql/sql_connect.cc:1419
#16 0x000055b34fd66ced in handle_one_connection (arg=arg@entry=0x55b35464d698) at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/sql/sql_connect.cc:1313
#17 0x000055b3500ee9ab in pfs_spawn_thread (arg=0x55b35464d708) at /data/fuxi_ci_workspace/6386108bbca18277f790c3ff/storage/perfschema/pfs.cc:2201
#18 0x00007f32b03cdf3b in ?? () from /usr/lib64/libpthread.so.0
#19 0x00007f32b0305840 in clone () from /usr/lib64/libc.so.6



 Comments   
Comment by Alice Sherepa [ 2022-12-21 ]

Thanks for the report!
I could not repeat the crash with the exact steps on 10.5.16, maybe it is dependent on server configuration or just sporadic and I had no luck with it.
But it is definitely a part of MDEV-24686 (the comment from 12-02-2022 leads to ~ the same crash)

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