Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Duplicate
-
10.8.3
-
Ubuntu 20.04
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).
Attachments
Issue Links
- duplicates
-
MDEV-29233 Assertion `lock_table_has(trx, index->table, LOCK_IX)' failed at lock0lock.cc:4972
-
- Closed
-
-
MDEV-29489 Assertion `lock_table_has(trx, index->table, LOCK_IX)' failed at lock0lock.cc:6025
-
- Closed
-
- relates to
-
MDEV-29560 Assertion `lock_table_has(trx, table, LOCK_IX)' failed in lock_trx_has_expl_x_lock
-
- Open
-
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.