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

InnoDB: Failing assertion: !other_lock || wsrep_thd_is_BF ... if innodb_lock_schedule_algorithm=VATS

Details

    Description

      Sorry, but the frontend did not allow me to fill in the MariaDB versions used.
      No replay on 10.1.35 commit 1d10c9afe0f2f4fba73892e6c12ea6efe90d5931.
      Replay on

      • 10.2.17 commit 400cf017152c732387c89deaa082b43c8fb42d71
      • 10.3.8 commit 71144afa966a85d08053eb616a1021fd339102d1
        all around 2018-07-02 + compiled with debug.

      Server error log entries + Backtrace of 10.3:
      		 
      InnoDB: Assertion failure in file storage/innobase/lock/lock0lock.cc line 5019
      		 
      InnoDB: Failing assertion: !other_lock || wsrep_thd_is_BF(lock->trx->mysql_thd, FALSE) || wsrep_thd_is_BF(other_lock->trx->mysql_thd, FALSE)
      		 
      ...
      		 
      Query: DELETE FROM t1 WHERE col1 = 1 OR col1 IS NULL  /* E_R Thread1 QNO 6083 CON_ID 15 */
      		 
      ...
      		 
      Status: NOT_KILLED
      		 
      #3  <signal handler called>
      		 
      #4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
      		 
      #5  0x00007f8acda5237a in __GI_abort () at abort.c:89
      		 
      #6  0x000055e6267f1eaf in ut_dbg_assertion_failed (expr=0x55e626e559d8 "!other_lock || wsrep_thd_is_BF(lock->trx->mysql_thd, FALSE) || wsrep_thd_is_BF(other_lock->trx->mysql_thd, FALSE)", file=0x55e626e53a40 "storage/innobase/lock/lock0lock.cc", line=5019) at storage/innobase/ut/ut0dbg.cc:61
      		 
      #7  0x000055e62664b06c in lock_rec_queue_validate (locked_lock_trx_sys=false, block=0x7f8aaba3e100, rec=0x7f8aac52c149 "", index=0x7f8a2c2cdb18, offsets=0x7f8ac41923b0) at storage/innobase/lock/lock0lock.cc:5017
      		 
      #8  0x000055e62664dd24 in lock_clust_rec_read_check_and_lock (flags=0, block=0x7f8aaba3e100, rec=0x7f8aac52c149 "", index=0x7f8a2c2cdb18, offsets=0x7f8ac41923b0, mode=LOCK_X, gap_mode=1024, thr=0x7f8a2c2de240) at storage/innobase/lock/lock0lock.cc:5862
      		 
      #9  0x000055e62674f5e1 in sel_set_rec_lock (pcur=0x7f8a2c2ddd38, rec=0x7f8aac52c149 "", index=0x7f8a2c2cdb18, offsets=0x7f8ac41923b0, mode=3, type=1024, thr=0x7f8a2c2de240, mtr=0x7f8ac4192cd0) at storage/innobase/row/row0sel.cc:1247
      		 
      #10 0x000055e6267588d4 in row_search_mvcc (buf=0x7f8a2c2dd720 "\377", mode=PAGE_CUR_G, prebuilt=0x7f8a2c2ddb78, match_mode=0, direction=0) at storage/innobase/row/row0sel.cc:5020
      		 
      #11 0x000055e6265c17bd in ha_innobase::index_read (this=0x7f8a2c2dcf90, buf=0x7f8a2c2dd720 "\377", key_ptr=0x0, key_len=0, find_flag=HA_READ_AFTER_KEY) at storage/innobase/handler/ha_innodb.cc:9315
      		 
      #12 0x000055e6265c2ab6 in ha_innobase::index_first (this=0x7f8a2c2dcf90, buf=0x7f8a2c2dd720 "\377") at storage/innobase/handler/ha_innodb.cc:9732
      		 
      #13 0x000055e6265c2cc5 in ha_innobase::rnd_next (this=0x7f8a2c2dcf90, buf=0x7f8a2c2dd720 "\377") at storage/innobase/handler/ha_innodb.cc:9825
      		 
      #14 0x000055e6263b16f1 in handler::ha_rnd_next (this=0x7f8a2c2dcf90, buf=0x7f8a2c2dd720 "\377") at sql/handler.cc:2764
      		 
      #15 0x000055e62652db86 in rr_sequential (info=0x7f8ac41935c0) at sql/records.cc:481
      		 
      #16 0x000055e62602aa5d in READ_RECORD::read_record (this=0x7f8ac41935c0) at sql/records.h:73
      		 
      #17 0x000055e62654ae08 in mysql_delete (thd=0x7f8a2c000a98, table_list=0x7f8a2c014c78, conds=0x7f8a2c0157b8, order_list=0x7f8a2c0052f0, limit=18446744073709551615, options=549755813888, result=0x0) at sql/sql_delete.cc:727
      		 
      #18 0x000055e6260c5c03 in mysql_execute_command (thd=0x7f8a2c000a98) at sql/sql_parse.cc:4916
      		 
      #19 0x000055e6260cfe9e in mysql_parse (thd=0x7f8a2c000a98, rawbuf=0x7f8a2c014b20 "DELETE FROM t1 WHERE col1 = 1 OR col1 IS NULL  /* E_R Thread1 QNO 6083 CON_ID 15 */", length=83, parser_state=0x7f8ac4194640, is_com_multi=false, is_next_command=false) at sql/sql_parse.cc:8076
      		 
      ...

      Attachments

        Issue Links

          is caused by

          Task - A task that needs to be done. MDEV-11039 Add new scheduling algorithm for reducing tail latencies

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-12837 WSREP: BF lock wait long

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-14552 Random crashes: Assertion failure in lock0lock.cc line 8150

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-15326 InnoDB: Failing assertion: !other_lock || wsrep_thd_is_BF(lock->trx->mysql_thd, FALSE) || wsrep_thd_is_BF(other_lock->trx->mysql_thd, FALSE)

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-23877 Document deprecation/removal of innodb_lock_schedule_algorithm

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-23897 ASAN SEGV in lock_grant_and_move_on_page

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed

          Task - A task that needs to be done. MDEV-30748 LOCKing mechanism Improvement Request that milestone of rdbms history

          • Major - Major loss of function.
          • Open
          links to

          Web Link see the discussion at the end of #248

          Activity

            Ascending order - Click to sort in descending order
            View 20 older comments
            marko Marko Mäkelä added a comment -

            MDEV-23877 was filed for documenting the deprecation of the parameter innodb_lock_schedule_algorithm.

            This ticket will be used for tracking the originally reported corruption that is caused by the setting innodb_lock_schedule_algorithm=VATS. Once the feature is fixed to work correctly, and if it has been demonstrated to improve performance, it can be permanently enabled in a later version. The code does not exist in the current MariaDB 10.6 development branch.

            marko Marko Mäkelä added a comment - MDEV-23877 was filed for documenting the deprecation of the parameter innodb_lock_schedule_algorithm . This ticket will be used for tracking the originally reported corruption that is caused by the setting innodb_lock_schedule_algorithm=VATS . Once the feature is fixed to work correctly, and if it has been demonstrated to improve performance, it can be permanently enabled in a later version. The code does not exist in the current MariaDB 10.6 development branch.
            jplindst Jan Lindström (Inactive) added a comment -

            Test case attached produces lock wait queue exactly as in crash case but still actual crash does not reproduce so there is something more needed.

            jplindst Jan Lindström (Inactive) added a comment - Test case attached produces lock wait queue exactly as in crash case but still actual crash does not reproduce so there is something more needed.
            marko Marko Mäkelä added a comment -

            While working on MDEV-20612, I noticed that possibly related to the MySQL 8.0 variant of this (called CATS), the deadlock detection was refactored and moved into a dedicated thread.

            marko Marko Mäkelä added a comment - While working on MDEV-20612 , I noticed that possibly related to the MySQL 8.0 variant of this (called CATS), the deadlock detection was refactored and moved into a dedicated thread .
            jplindst Jan Lindström (Inactive) added a comment -

            Unfortunately, I have not found a test case that would reproduce this and my guess fixes do not work. Therefore, I must say based on my current knowledge that I do not know how to fix this issue. If we want maybe we should use same as MySQL 8.0 (this change might be out of 10.6 scope).

            jplindst Jan Lindström (Inactive) added a comment - Unfortunately, I have not found a test case that would reproduce this and my guess fixes do not work. Therefore, I must say based on my current knowledge that I do not know how to fix this issue. If we want maybe we should use same as MySQL 8.0 (this change might be out of 10.6 scope).
            marko Marko Mäkelä added a comment -

            This was fixed in MariaDB Server 10.6.0 by removing the parameter.

            marko Marko Mäkelä added a comment - This was fixed in MariaDB Server 10.6.0 by removing the parameter .

            People

              marko Marko Mäkelä
              mleich Matthias Leich
              Votes:
              1 Vote for this issue
              Watchers:
              13 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.