sh[21888]: 2021-01-12  6:23:08 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.

sh[21888]: 2021-01-12  6:23:09 0 [Note] InnoDB: 128 rollback segments are active.

sh[21888]: 2021-01-12  6:23:09 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"

sh[21888]: 2021-01-12  6:23:09 0 [Note] InnoDB: Creating shared tablespace for temporary tables

sh[21888]: 2021-01-12  6:23:09 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...

sh[21888]: 2021-01-12  6:23:09 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.

sh[21888]: 2021-01-12  6:23:09 0 [Note] InnoDB: 10.5.8 started; log sequence number 1584788811151; transaction id 7795002400535230266

sh[21888]: 2021-01-12  6:23:09 0 [Warning] InnoDB: Skipping buffer pool dump/restore during wsrep recovery.

sh[21888]: 2021-01-12 06:23:09 0x7f80a4f46700  InnoDB: Assertion failure in file /home/buildbot/buildbot/build/mariadb-10.5.8/storage/innobase/include/fut0lst.h line 127

sh[21888]: InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA

sh[21888]: InnoDB: We intentionally generate a memory trap.

sh[21888]: InnoDB: Submit a detailed bug report to https://jira.mariadb.org/

sh[21888]: InnoDB: If you get repeated assertion failures or crashes, even

sh[21888]: InnoDB: immediately after the mysqld startup, there may be

sh[21888]: InnoDB: corruption in the InnoDB tablespace. Please refer to

sh[21888]: InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/

sh[21888]: InnoDB: about forcing recovery.

sh[21888]: 210112  6:23:09 [ERROR] mysqld got signal 6 ;

sh[21888]: This could be because you hit a bug. It is also possible that this binary

sh[21888]: or one of the libraries it was linked against is corrupt, improperly built,

sh[21888]: or misconfigured. This error can also be caused by malfunctioning hardware.

sh[21888]: To report this bug, see https://mariadb.com/kb/en/reporting-bugs

sh[21888]: We will try our best to scrape up some info that will hopefully help

sh[21888]: diagnose the problem, but since we have already crashed,

sh[21888]: something is definitely wrong and this may fail.

sh[21888]: Server version: 10.5.8-MariaDB-1:10.5.8+maria~bionic

sh[21888]: key_buffer_size=134217728

sh[21888]: read_buffer_size=2097152

sh[21888]: max_used_connections=0

sh[21888]: max_threads=1002

sh[21888]: thread_count=0

sh[21888]: It is possible that mysqld could use up to

sh[21888]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6312783 K  bytes of memory

sh[21888]: Hope that's ok; if not, decrease some variables in the equation.

sh[21888]: Thread pointer: 0x7f8090000cf8

sh[21888]: Attempting backtrace. You can use the following information to find out

sh[21888]: where mysqld died. If you see no messages after this, something went

sh[21888]: terribly wrong...

sh[21888]: 2021-01-12  6:23:09 0 [Note] Plugin 'FEEDBACK' is disabled.

sh[21888]: stack_bottom = 0x7f80a4f45c98 thread_stack 0x49000

sh[21888]: 2021-01-12  6:23:09 0 [Note] Recovering after a crash using tc.log

sh[21888]: 2021-01-12  6:23:09 0 [Note] Starting crash recovery...

sh[21888]: 2021-01-12  6:23:09 0 [Note] Crash recovery finished.

sh[21888]: 2021-01-12  6:23:09 0 [Note] Server socket created on IP: '0.0.0.0'.

sh[21888]: 2021-01-12  6:23:09 0 [Note] WSREP: Recovered position: 7f74fdea-cda3-11e9-ae2f-ab188b9a01f2:338545194

sh[21888]: ??:0(my_print_stacktrace)[0x55614e3ad25e]

sh[21888]: ??:0(handle_fatal_signal)[0x55614ddbb715]

sh[21888]: ??:0(__restore_rt)[0x7f8146a25980]

sh[21888]: ??:0(gsignal)[0x7f8145d35fb7]

sh[21888]: ??:0(abort)[0x7f8145d37921]

sh[21888]: /usr/sbin/mysqld(+0x605032)[0x55614dab7032]

sh[21888]: ??:0(std::_Rb_tree<unsigned int, unsigned int, std::_Identity<unsigned int>, std::less<unsigned int>, std::allocator<unsigned int> >::_M_erase(std::_Rb_tree_node<unsigned int>*))[0x55614e1d5546]

sh[21888]: ??:0(std::_Rb_tree<unsigned int, unsigned int, std::_Identity<unsigned int>, std::less<unsigned int>, std::allocator<unsigned int> >::_M_erase(std::_Rb_tree_node<unsigned int>*))[0x55614e1d5849]

sh[21888]: ??:0(std::_Rb_tree<unsigned int, unsigned int, std::_Identity<unsigned int>, std::less<unsigned int>, std::allocator<unsigned int> >::_M_erase(std::_Rb_tree_node<unsigned int>*))[0x55614e1dab87]

sh[21888]: ??:0(std::unique_lock<std::mutex>::unlock())[0x55614e1bdc73]

sh[21888]: ??:0(tpool::task_group::execute(tpool::task*))[0x55614e335224]

sh[21888]: ??:0(tpool::thread_pool_generic::worker_main(tpool::worker_data*))[0x55614e3340ef]

sh[21888]: ??:0(std::error_code::default_error_condition() const)[0x7f81465436df]

sh[21888]: ??:0(start_thread)[0x7f8146a1a6db]

sh[21888]: ??:0(clone)[0x7f8145e1871f]

sh[21888]: Trying to get some variables.

sh[21888]: Some pointers may be invalid and cause the dump to abort.

sh[21888]: Query (0x0): (null)

sh[21888]: Connection ID (thread ID): 0

sh[21888]: Status: NOT_KILLED

sh[21888]: 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

sh[21888]: The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains

sh[21888]: information that should help you find out what is causing the crash.

sh[21888]: We think the query pointer is invalid, but we will try to print it anyway.

sh[21888]: Query:

sh[21888]: Writing a core file...

sh[21888]: Working directory at /var/lib/mysql

sh[21888]: Resource Limits:

sh[21888]: Limit                     Soft Limit           Hard Limit           Units

sh[21888]: Max cpu time              unlimited            unlimited            seconds

sh[21888]: Max file size             unlimited            unlimited            bytes

sh[21888]: Max data size             unlimited            unlimited            bytes

sh[21888]: Max stack size            8388608              unlimited            bytes

sh[21888]: Max core file size        0                    unlimited            bytes

sh[21888]: Max resident set          unlimited            unlimited            bytes

sh[21888]: Max processes             63772                63772                processes

sh[21888]: Max open files            1048576              1048576              files

sh[21888]: Max locked memory         16777216             16777216             bytes

sh[21888]: Max address space         unlimited            unlimited            bytes

sh[21888]: Max file locks            unlimited            unlimited            locks

sh[21888]: Max pending signals       63772                63772                signals

sh[21888]: Max msgqueue size         819200               819200               bytes

sh[21888]: Max nice priority         0                    0

sh[21888]: Max realtime priority     0                    0

sh[21888]: Max realtime timeout      unlimited            unlimited            us

sh[21888]: Core pattern: core

sh[21888]: Aborted'