Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-29118

Assertion `lock_table_has(trx, index->table, LOCK_IX)' failed at lock0lock.cc:4972

Details

    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

          Activity

            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.

            marko Marko Mäkelä added a comment - 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.

            People

              vlad.lesin Vladislav Lesin
              Zuming Jiang Zuming Jiang
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.