[MDEV-29118] Assertion `lock_table_has(trx, index->table, LOCK_IX)' failed at lock0lock.cc:4972 Created: 2022-07-18  Updated: 2023-09-04  Resolved: 2023-03-30

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Insert, Locking, Storage Engine - InnoDB
Affects Version/s: 10.8.3
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Zuming Jiang Assignee: Vladislav Lesin
Resolution: Duplicate Votes: 0
Labels: crash
Environment:

Ubuntu 20.04


Attachments: Text File bug_report.txt     File mysql_bk.sql    
Issue Links:
Duplicate
duplicates MDEV-29233 Assertion `lock_table_has(trx, index-... Closed
duplicates MDEV-29489 Assertion `lock_table_has(trx, index-... Closed
Relates
relates to MDEV-29560 Assertion `lock_table_has(trx, table,... Open

 Description   

I used my fuzzing tool to test MariaDB and found a transaction-related bug that make the crashes.

Mariadb installation
1) cd mariadb-10.8.3
2) mkdir build; cd build
3) cmake .. -DCMAKE_BUILD_TYPE=Debug
4) make -j12 && sudo make install

Setup the environment
1) export ASAN_OPTIONS=detect_leaks=0
2) /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql &
3) /usr/local/mysql/bin/mysql -uroot -Dtestdb < mysql_bk.sql (attached) # set up the database

Reproduce bug

/usr/local/mysql/bin/mysql -uroot -Dtestdb # set up connection conn_0
/usr/local/mysql/bin/mysql -uroot -Dtestdb # set up connection conn_1

conn_0> START TRANSACTION;

conn_0> delete from t_davsbd;

conn_1> START TRANSACTION;

conn_1> insert into t_iqij_c (wkey, pkey, c_svp9sc, c_anyvkb) values
(115, 222000, ASCII('w_3pab'), null),
(115, 223000, CHAR_LENGTH(
case when ((select wkey from t_j4mbqd order by wkey limit 1 offset 34)
in (select ref_0.pkey as c0 from t_davsbd as ref_0))
then 'k0hpvb' else 'sss' end), null); --- this INSERT blocks

conn_0> update t_j4mbqd set wkey = 190; --- this UPDATE make the above INSERT crash the maridb server

conn_0> ROLLBACK;

conn_1> ROLLBACK;

I have simplified the content of the test case, and I hope this report can help you reproduce and fix the bug. In addition, I attached the failure report (which has its stack trace).



 Comments   
Comment by Marko Mäkelä [ 2022-07-18 ]

Thank you for the report. The invariant is that locks on index records may only be acquired it the transaction is already holding a similar table lock. For INSERT, UPDATE, or DELETE that would be an intention-exclusive (IX) lock. For checks of FOREIGN KEY constraints, that would be IS and a shared record lock.

Before analyzing or debugging this (https://rr-project.org and some data watchpoints should be perfect for this), I would guess that the issue is that the INSERT transaction was supposed to be aborted altogether, but somehow the lock wait logic failed to do that.

The locking code went through major changes in the 10.6 release. It might be that this bug scenario does not affect older releases. It might also be that older major releases are missing an equivalent assertion.

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