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

Crash in deadlock checker under high load

Details

    Description

      Under a High load with multiple rollbacks a crash is observed at:

      2021-05-03 16:51:03 0x7fe56f780700 InnoDB: Assertion failure in file /home/jenkins/workspace/MariaDBE-Custom-DEB/label/ubuntu-1804/MariaDBEnterprise/storage/innobase/lock/lock0lock.cc line 6780

      Attachments

        Issue Links

          causes

          Bug - A problem which impairs or prevents the functions of the product. MDEV-26123 Using Spatial Indexes results in Update locks cannot be acquired during a READ UNCOMMITTED transaction

          • Critical - Crashes, loss of data, severe memory leak.
          • Stalled
          is duplicated by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-26291 ER_FILSORT_ABORT triggers - crash query when "for update" in a select statement

          • Major - Major loss of function.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-21987 Assertion failure in file lock0lock.cc line 6901 / DeadlockChecker::check_and_resolve

          • Major - Major loss of function.
          • Confirmed

          Task - A task that needs to be done. MDEV-24738 Improve the InnoDB deadlock checker

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-25125 Draft: InnoDB: Assertion failure in trx0i_s.cc line 1167 upon SELECT * FROM information_schema.innodb_trx

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-25163 Rowid filter does not process storage engine error correctly.

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-26050 InnoDB: Assertion failure in lock0lock.cc line 6942

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            View 5 older comments
            kjoiner Kyle Joiner (Inactive) added a comment -

            The debug executable has never crashed.

            kjoiner Kyle Joiner (Inactive) added a comment - The debug executable has never crashed.
            marko Marko Mäkelä added a comment -

            Even though we did not find the root cause of the problem yet, I pushed the SPATIAL INDEX fix to 10.2 and merged up to 10.5. I also pushed the change of trx_t::will_lock to bool to 10.5. These will probably not explain the reported crash. I’m leaving this ticket open until more information is available of the crash. It could be very helpful to have a core dump (along with a copy of the executable and shared libraries that produced it).

            marko Marko Mäkelä added a comment - Even though we did not find the root cause of the problem yet, I pushed the SPATIAL INDEX fix to 10.2 and merged up to 10.5. I also pushed the change of trx_t::will_lock to bool to 10.5. These will probably not explain the reported crash. I’m leaving this ticket open until more information is available of the crash. It could be very helpful to have a core dump (along with a copy of the executable and shared libraries that produced it).
            marko Marko Mäkelä added a comment -

            A development snapshot that did not differ much from the 10.5.10 release and included some fixes was provided to the customer, and the problems did not occur anymore.

            We cannot conclude if that is thanks to the cleanup (such as changing trx_t::will_lock from a counter to bool) or due to other changes between 10.5.9 and 10.5.10, possibly in the SQL layer, so that a transaction abort would no longer be ignored. (One example of that is in MDEV-21987.) I think that we can close this for now anyway.

            marko Marko Mäkelä added a comment - A development snapshot that did not differ much from the 10.5.10 release and included some fixes was provided to the customer, and the problems did not occur anymore. We cannot conclude if that is thanks to the cleanup (such as changing trx_t::will_lock from a counter to bool ) or due to other changes between 10.5.9 and 10.5.10, possibly in the SQL layer, so that a transaction abort would no longer be ignored. (One example of that is in MDEV-21987 .) I think that we can close this for now anyway.
            marko Marko Mäkelä added a comment -

            I ported the additional code cleanup from 10.5 to earlier major versions.

            marko Marko Mäkelä added a comment - I ported the additional code cleanup from 10.5 to earlier major versions .
            danblack Daniel Black added a comment -

            mosmani, that's something different.

            Please create a new bug report with a more complete backtrace.

            This assertion in btr_check_blob_fil_page_type isn't something I've found in existing issues.

            Please include details of the sorts of SQL operations performed on blob columns especially if the error log doesn't include a SQL query.

            danblack Daniel Black added a comment - mosmani , that's something different. Please create a new bug report with a more complete backtrace. This assertion in btr_check_blob_fil_page_type isn't something I've found in existing issues. Please include details of the sorts of SQL operations performed on blob columns especially if the error log doesn't include a SQL query.

            People

              marko Marko Mäkelä
              kjoiner Kyle Joiner (Inactive)
              Votes:
              2 Vote for this issue
              Watchers:
              6 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.