[MDEV-13262] innodb.deadlock_detect failed in buildbot Created: 2017-07-06  Updated: 2018-01-08  Resolved: 2018-01-08

Status: Closed
Project: MariaDB Server
Component/s: Tests
Affects Version/s: 10.2
Fix Version/s: 10.3.4, 10.2.13

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 0
Labels: 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



 Comments   
Comment by Alice Sherepa [ 2017-09-07 ]

failed on 10.3 (sporadic) http://buildbot.askmonty.org/buildbot/builders/winx64-packages/builds/4754/steps/test/logs/stdio

Comment by Jan Lindström (Inactive) [ 2018-01-04 ]

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.

Comment by Jan Lindström (Inactive) [ 2018-01-08 ]

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.

Generated at Thu Feb 08 08:04:12 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.