[MDEV-25017] mariadb restart Created: 2021-02-26  Updated: 2023-05-12  Resolved: 2023-05-12

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.3
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: gao Assignee: Marko Mäkelä
Resolution: Incomplete Votes: 0
Labels: None
Environment:

10.3.13-MariaDB


 Description   

2021-02-26 07:00:40 0x7fd88034f700 InnoDB: Assertion failure in file /mysql_log/mysql/mariadb-10.3.13/storage/innobase/lock/lock0lock.cc line 7022
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.
210226 7:00:40 [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.3.13-MariaDB-log

 Comments   
Comment by gao [ 2021-02-26 ]

the database server restart at 7:00 every day this week, so weird

Comment by Marko Mäkelä [ 2023-04-14 ]

Sorry, I had overlooked this report.

The crash occurs in the following code:

const trx_t*
 
DeadlockChecker::check_and_resolve(const lock_t* lock, trx_t* trx)
 
{
 
        ut_ad(lock_mutex_own());
 
        ut_ad(trx_mutex_own(trx));
 
        check_trx_state(trx);

Does this occur with a more recent version of MariaDB? There have been numerous fixes to the locking code since then, such as MDEV-15326 and MDEV-28422. This bug could also be caused by an error in the SQL layer, such as MDEV-10087.

I suppose that some scheduled reporting activity will cause occasional deadlocks between transactions, which then causes this sanity check to fail.

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