[MDEV-25708] THD::cleanup(): Assertion `!mdl_context.has_locks()' failed Created: 2021-05-17  Updated: 2021-05-23  Resolved: 2021-05-23

Status: Closed
Project: MariaDB Server
Component/s: Galera, Triggers
Affects Version/s: 10.5, 10.6
Fix Version/s: 10.6.2, 10.5.11

Type: Bug Priority: Blocker
Reporter: Julius Goryavsky Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: regression-10.5, regression-10.6

Issue Links:
Relates
relates to MDEV-25738 Assertion `ticket->m_duration == MDL_... Closed
relates to MDEV-25606 Concurrent CREATE TRIGGER statements ... Closed
relates to MDEV-25651 Server crash or assertion failure in ... Closed

 Description   

Failure during wsrep_mode_strict_replication test:

galera.wsrep_mode_strict_replication 'innodb' w1 [ fail ]  Found warnings/errors in server log file!
 
        Test ended at 2021-05-15 13:36:58
 
line
 
mariadbd: /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.6.1/sql/sql_class.cc:1590: void THD::cleanup(): Assertion `!mdl_context.has_locks()' failed.
 
Attempting backtrace. You can use the following information to find out
 
^ Found warnings in /dev/shm/var/1/log/mysqld.1.err
 
ok



 Comments   
Comment by Julius Goryavsky [ 2021-05-18 ]

One more test failure caused by the same merge:

galera_sr.mysql-wsrep-features#8 'innodb' [ fail ]
 
        Test ended at 2021-05-18 03:51:33
 
 
 
CURRENT_TEST: galera_sr.mysql-wsrep-features#8
 
mysqltest: At line 37: query 'SELECT COUNT(f2) = 10000 FROM t1 WHERE MATCH(f2) AGAINST ('abcdefjhk')' failed: 1205: Lock wait timeout exceeded; try restarting transaction
 
 
 
The result from queries just before the failure was:
 
< snip >
 
CREATE TABLE t1 (f1 INT PRIMARY KEY AUTO_INCREMENT, f2 VARCHAR(100), FULLTEXT (f2)) ENGINE=InnoDB;
 
connection node_2;
 
SELECT COUNT(*) = 13 FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE name LIKE 'test/%';
 
COUNT(*) = 13
 
1
 
connection node_1;
 
INSERT INTO t1 (f2) SELECT 'foobarbaz' FROM ten AS a1, ten AS a2, ten AS a3, ten AS a4;
 
connection node_2;
 
SELECT COUNT(f2) = 10000 FROM t1 WHERE MATCH(f2) AGAINST ('foobarbaz');
 
COUNT(f2) = 10000
 
1
 
UPDATE t1 SET f2 = 'abcdefjhk';
 
connection node_1;
 
SELECT COUNT(f2) = 10000 FROM t1 WHERE MATCH(f2) AGAINST ('abcdefjhk');

Comment by Marko Mäkelä [ 2021-05-18 ]

MDEV-25606 and MDEV-25651 are possible culprits according to the output of the following:

git log --oneline 370b310b1d67ad42df96b75c3876fdcf67a8694f^..370b310b1d67ad42df96b75c3876fdcf67a8694f^2 sql

Comment by Marko Mäkelä [ 2021-05-18 ]

It looks like this affects 10.5 as well. I just got this failure locally:

10.5 81402c131875c5fc2c3c4078bc12770304a48861 with a merge from 10.4

 
galera.wsrep_strict_ddl 'innodb'         w5 [ fail ]  Found warnings/errors in server log file!
 
        Test ended at 2021-05-18 09:06:34
 
line
 
mariadbd: /mariadb/10.5m/sql/sql_class.cc:1588: void THD::cleanup(): Assertion `!mdl_context.has_locks()' failed.

Unfortunately, no stack trace or core dump was preserved.

Comment by Michael Widenius [ 2021-05-23 ]

The last comment is not related to Jira entry case, as the test
galera.wsrep_mode_strict_replication only exists in 10.6

Comment by Michael Widenius [ 2021-05-23 ]

I tested galera_sr.mysql-wsrep-features#8 with latest 10.5 and it worked with me. Nothing that I can do related to that as there is no information of what failed and there is no stack trace in the comment.

galera.wsrep_strict_ddl failed, will fix that.

The reason for the failure in galera was that error handling was not done properly.
Having macros that jumps to lablels that does not do error recovery is NOT A GOOD IDEA!
Fixed by doing proper error recovery in case of WSREP falures

Comment by Michael Widenius [ 2021-05-23 ]

Pushed bug fix into 10.5 tree

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