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

innodb.deadlock_detect failed in buildbot

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.2(EOL)
    • 10.3.4, 10.2.13
    • Tests
    • None

    Description

      http://buildbot.askmonty.org/buildbot/builders/kvm-deb-wheezy-x86/builds/4832/steps/mtr/logs/stdio

      innodb.deadlock_detect 'innodb'          w4 [ fail ]
              Test ended at 2017-07-04 08:46:49
       
      CURRENT_TEST: innodb.deadlock_detect
      mysqltest: At line 44: query 'reap' succeeded - should have failed with errno 1205...
       
      The result from queries just before the failure was:
      < snip >
      id	INT,
      PRIMARY KEY(id)
      ) ENGINE=InnoDB;
      INSERT INTO t1 VALUES(1), (2), (3);
      BEGIN;
      SELECT * FROM t1 WHERE id = 1 FOR UPDATE;
      id
      1
      connect  con1,localhost,root,,;
      BEGIN;
      SELECT * FROM t1 WHERE id = 2 FOR UPDATE;
      id
      2
      SELECT * FROM t1 WHERE id = 1 FOR UPDATE;
      connection default;
      SELECT * FROM t1 WHERE id = 2 FOR UPDATE;
      connection con1;
      ERROR HY000: Lock wait timeout exceeded; try restarting transaction
      ROLLBACK;
      connection default;
       
      More results from queries before failure can be found in /run/shm/var/4/log/deadlock_detect.log
      

      Attachments

        Activity

          alice Alice Sherepa added a comment - failed on 10.3 (sporadic) http://buildbot.askmonty.org/buildbot/builders/winx64-packages/builds/4754/steps/test/logs/stdio
          jplindst Jan Lindström (Inactive) added a comment - - edited

          ok could repeat using 10.2-compatibility and windows. Problem seems to be that first transaction could get lock wait timeout (and then rolled back) before second will get it and naturally second will succeed then.

          jplindst Jan Lindström (Inactive) added a comment - - edited ok could repeat using 10.2-compatibility and windows. Problem seems to be that first transaction could get lock wait timeout (and then rolled back) before second will get it and naturally second will succeed then.

          commit ae7e1b9b13ddc23167bd058ff4718ac116d17126
          Author: Jan Lindström <jan.lindstrom@mariadb.com>
          Date: Mon Jan 8 12:25:31 2018 +0200

          MDEV-13262: innodb.deadlock_detect failed in buildbot

          There is a race condition on a test. con1 is the older transaction
          as it query started wait first. Test continues so that con1 gets
          lock wait timeout first. There is possibility that default connection
          gets lock timeout also or as con1 is rolled back it gets the locks
          it waited and does the update. Fixed by removing query outputs as
          they could vary and accepting success from default connection
          query.

          jplindst Jan Lindström (Inactive) added a comment - commit ae7e1b9b13ddc23167bd058ff4718ac116d17126 Author: Jan Lindström <jan.lindstrom@mariadb.com> Date: Mon Jan 8 12:25:31 2018 +0200 MDEV-13262 : innodb.deadlock_detect failed in buildbot There is a race condition on a test. con1 is the older transaction as it query started wait first. Test continues so that con1 gets lock wait timeout first. There is possibility that default connection gets lock timeout also or as con1 is rolled back it gets the locks it waited and does the update. Fixed by removing query outputs as they could vary and accepting success from default connection query.

          People

            jplindst Jan Lindström (Inactive)
            elenst Elena Stepanova
            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.