Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Duplicate
-
10.5.12
-
FreeBSD 12.2 + base ZFS + jail
Description
Dear Sirs,
After upgrading 3 of our mariadb servers from 10.5.11 to 10.5.12 we encounter this bug after around a week from the upgrade.
The mariadb servers are running in a standard default configuration and upgraded regularly for several years.
We thought that the bug may be related to this modification : MDEV-24393, so we disabled the skip_external_locking trying to have the advisory lock back but in vain, we still have the bug, mainly with the INSERT and CREATE statements.
Here is a log of one of the cases :
InnoDB: Assertion failure in file /usr/ports/databases/mariadb105-server/work/mariadb-10.5.12/storage/innobase/fsp/fsp0fsp.cc line 1535
|
InnoDB: Failing assertion: inode
|
InnoDB: We intentionally generate a memory trap.
|
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/ InnoDB: If you get repeated assertion failures or crashes, even
|
InnoDB: immediately after the mysqld startup, there may be
|
InnoDB: corruption in the InnoDB tablespace. Please refer to
|
InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
|
InnoDB: about forcing recovery.
|
210816 13:40:17 [ERROR] mysqld got signal 6 ;
|
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.12-MariaDB
|
key_buffer_size=1073741824
|
read_buffer_size=2097152
|
max_used_connections=56
|
max_threads=1026
|
thread_count=61
|
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 5276648 K bytes of memory
|
Hope that's ok; if not, decrease some variables in the equation.
|
|
Thread pointer: 0x8edaba698
|
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 = 0x7fffdb35ae50 thread_stack 0x49000
|
0x132cdfc <my_print_stacktrace+0x3c> at /usr/local/libexec/mariadbd
|
0xc75cbe <handle_fatal_signal+0x28e> at /usr/local/libexec/mariadbd
|
0x80191bd20 <_pthread_sigmask+0x530> at /lib/libthr.so.3
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0x0): (null)
|
Connection ID (thread ID): 0
|
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_pu
|
shdown=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_ca
|
che=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=o
|
n,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.
|
 |
We think the query pointer is invalid, but we will try to print it anyway.
|
Query:
|
 |
Core pattern: %N.core
|
So, now we downgraded them back to 10.5.11, and working on a staging server to try to debug it.
Thank you for any help you can give us.
Regards
LQ
Attachments
Issue Links
- duplicates
-
-
- Closed
-