[MDEV-26799] Found wrong usage of mutex 'LOCK_thd_kill' and 'LOCK_wsrep_server_state Created: 2021-10-11  Updated: 2022-04-07  Resolved: 2021-10-21

Status: Closed
Project: MariaDB Server
Component/s: Galera, Tests
Affects Version/s: 10.4
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Jan Lindström (Inactive) Assignee: Daniele Sciascia
Resolution: Fixed Votes: 0
Labels: None


 Description   

 galera_sr.mysql-wsrep-features#27 (Failed 4 times in the last 30 runs. Flakiness: 24%, Stability: 86%)
 Stack Trace
CREATE TABLE t1 (f1 INTEGER PRIMARY KEY) ENGINE=InnoDB;
SET SESSION wsrep_trx_fragment_size = 1;
SET AUTOCOMMIT=OFF;
START TRANSACTION;
INSERT INTO t1 VALUES (1);
INSERT INTO t1 VALUES (2);
INSERT INTO t1 VALUES (3);
INSERT INTO t1 VALUES (4);
INSERT INTO t1 VALUES (5);
connect node_1a, 127.0.0.1, root, , test, $NODE_MYPORT_1;
ALTER TABLE t1 ADD COLUMN f2 INTEGER;
connection node_2;
SET SESSION wsrep_sync_wait = 0;
SELECT COUNT(*) = 0 FROM t1;
COUNT(*) = 0
1
connection node_1;
COMMIT;
ERROR 40001: Deadlock found when trying to get lock; try restarting transaction
DROP TABLE t1;
line
safe_mutex: Found wrong usage of mutex 'LOCK_thd_kill' and 'LOCK_wsrep_server_state'
^ Found warnings in /var/tmp/mtr/2/log/mysqld.1.err



 Comments   
Comment by Jan Lindström (Inactive) [ 2021-10-11 ]
  • How to reproduce: Not known, very sporadically

safe_mutex: Found wrong usage of mutex 'LOCK_thd_kill' and 'LOCK_wsrep_server_state'
Mutex currently locked (in reverse order):
LOCK_wsrep_server_state           /home/jenkins/workspace/10.4e-bintars-ENTERPRISE/BuildType/Debug/label/debian-10/sql/wsrep_mutex.h  line 34
LOCK_thd_kill                     /home/jenkins/workspace/10.4e-bintars-ENTERPRISE/BuildType/Debug/label/debian-10/sql/service_wsrep.cc  line 42

Comment by Daniele Sciascia [ 2021-10-12 ]

Can't reproduce this on my machine. I always get the wrong usage of mutex I reported in MDEV-26528.

Comment by Jan Lindström (Inactive) [ 2021-10-21 ]

Problem could be fixed but 10.4 was not yet rebased.

Generated at Thu Feb 08 09:48:01 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.