[MDEV-11168] InnoDB: Failing assertion: !other_lock || wsrep_thd_is_BF(lock->trx->mysql_thd, FALSE) || wsrep_thd_is_BF(other_lock->trx->mysql_thd, FALSE) Created: 2016-10-28  Updated: 2018-07-05  Resolved: 2016-12-02

Status: Closed
Project: MariaDB Server
Component/s: Locking, Storage Engine - InnoDB, Storage Engine - XtraDB
Affects Version/s: 10.1.19, 10.2
Fix Version/s: 10.1.20, 10.2.3

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Attachments: HTML File threads    
Issue Links:
Problem/Incident
is caused by MDEV-11039 Add new scheduling algorithm for redu... Closed
Sprint: 10.2.4-4

 Description   

10.2 39d2c7b18d

2016-10-29 01:13:14 0x7fdc558c5300  InnoDB: Assertion failure in thread 140584304792320 in file lock0lock.cc line 6347
InnoDB: Failing assertion: !other_lock || wsrep_thd_is_BF(lock->trx->mysql_thd, FALSE) || wsrep_thd_is_BF(other_lock->trx->mysql_thd, FALSE)
 
#6  0x00007fdc54ef8ab4 in ut_dbg_assertion_failed (expr=expr@entry=0x7fdc55374cd8 "!other_lock || wsrep_thd_is_BF(lock->trx->mysql_thd, FALSE) || wsrep_thd_is_BF(other_lock->trx->mysql_thd, FALSE)", file=file@entry=0x7fdc55373bc8 "/data/src/10.2/storage/innobase/lock/lock0lock.cc", line=line@entry=6347) at /data/src/10.2/storage/innobase/ut/ut0dbg.cc:67
#7  0x00007fdc54d52f97 in lock_rec_queue_validate (locked_lock_trx_sys=locked_lock_trx_sys@entry=0, block=block@entry=0x7fdc3dbb41a0, rec=rec@entry=0x7fdc3dec407e "", index=index@entry=0x7fdc2d55cd88, offsets=offsets@entry=0x7fdc558c0cc0) at /data/src/10.2/storage/innobase/lock/lock0lock.cc:6346
#8  0x00007fdc54d5c5c5 in lock_clust_rec_read_check_and_lock (flags=flags@entry=0, block=block@entry=0x7fdc3dbb41a0, rec=rec@entry=0x7fdc3dec407e "", index=index@entry=0x7fdc2d55cd88, offsets=offsets@entry=0x7fdc558c0cc0, mode=mode@entry=LOCK_X, gap_mode=0, thr=0x7fdc2d69dab0) at /data/src/10.2/storage/innobase/lock/lock0lock.cc:7166
#9  0x00007fdc54e4d785 in sel_set_rec_lock (pcur=pcur@entry=0x7fdc2d69d270, rec=rec@entry=0x7fdc3dec407e "", index=index@entry=0x7fdc2d55cd88, offsets=0x7fdc558c0cc0, mode=3, type=0, thr=0x7fdc2d69dab0, mtr=0x7fdc558c1300) at /data/src/10.2/storage/innobase/row/row0sel.cc:1255
#10 0x00007fdc54e52b4a in row_search_mvcc (buf=buf@entry=0x7fdc2d41c188 "\377", mode=mode@entry=PAGE_CUR_G, prebuilt=0x7fdc2d69d088, match_mode=match_mode@entry=0, direction=direction@entry=0) at /data/src/10.2/storage/innobase/row/row0sel.cc:5358
#11 0x00007fdc54cf79bb in ha_innobase::index_read (this=0x7fdc2d4b5888, buf=0x7fdc2d41c188 "\377", key_ptr=0x0, key_len=<optimized out>, find_flag=<optimized out>) at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:10431
#12 0x00007fdc54ce32a4 in ha_innobase::index_first (this=0x7fdc2d4b5888, buf=0x7fdc2d41c188 "\377") at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:10878
#13 0x00007fdc54cf8189 in ha_innobase::rnd_next (this=0x7fdc2d4b5888, buf=0x7fdc2d41c188 "\377") at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:10979
#14 0x00007fdc54b05155 in handler::ha_rnd_next (this=0x7fdc2d4b5888, buf=0x7fdc2d41c188 "\377") at /data/src/10.2/sql/handler.cc:2577
#15 0x00007fdc54c36ea7 in rr_sequential (info=0x7fdc558c1b70) at /data/src/10.2/sql/records.cc:474
#16 0x00007fdc549d58d2 in mysql_update (thd=thd@entry=0x7fdc2d816070, table_list=0x7fdc2d864160, fields=..., values=..., conds=0x0, order_num=<optimized out>, order=<optimized out>, limit=18446744073709551615, handle_duplicates=DUP_ERROR, ignore=false, found_return=0x7fdc558c20e0, updated_return=0x7fdc558c2190) at /data/src/10.2/sql/sql_update.cc:737
#17 0x00007fdc54920ae4 in mysql_execute_command (thd=thd@entry=0x7fdc2d816070) at /data/src/10.2/sql/sql_parse.cc:4176
#18 0x00007fdc549276cb in mysql_parse (thd=thd@entry=0x7fdc2d816070, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x7fdc558c38e0, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/10.2/sql/sql_parse.cc:7796
#19 0x00007fdc5492999b in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x7fdc2d816070, packet=packet@entry=0x7fdc2d858071 "UPDATE t1 SET i1 = 1", packet_length=packet_length@entry=20, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/10.2/sql/sql_parse.cc:1806
#20 0x00007fdc5492c4cd in do_command (thd=0x7fdc2d816070) at /data/src/10.2/sql/sql_parse.cc:1366
#21 0x00007fdc54a190f0 in do_handle_one_connection (connect=connect@entry=0x7fdc51c71870) at /data/src/10.2/sql/sql_connect.cc:1354
#22 0x00007fdc54a192d9 in handle_one_connection (arg=arg@entry=0x7fdc51c71870) at /data/src/10.2/sql/sql_connect.cc:1260
#23 0x00007fdc54cbe699 in pfs_spawn_thread (arg=0x7fdc393eb9f0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
#24 0x00007fdc540390a4 in start_thread (arg=0x7fdc558c5300) at pthread_create.c:309
#25 0x00007fdc5285987d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

--source include/have_innodb.inc
 
CREATE TABLE t1 (i1 INT) ENGINE=InnoDB;
INSERT INTO t1 VALUES (1),(2);
 
CREATE TABLE t2 (i2 int) ENGINE=MyISAM;
BEGIN;
DELETE FROM t1;
 
--connect (con1,localhost,root,,test)
BEGIN;
INSERT INTO t2 VALUES (1),(2);
UPDATE t1 SET i1 = 1;



 Comments   
Comment by Elena Stepanova [ 2016-11-05 ]

This problem is quite a nuisance for tests, it would be good to have it fixed.

Comment by Nirbhay Choubey (Inactive) [ 2016-11-30 ]

10.1 is affected too, it's just that the related code is removed with #ifndef WITH_WSREP.

Comment by Jan Lindström (Inactive) [ 2016-12-01 ]

commit 84263a2f64ab78fb53633a78d0522509386721e0
Author: Jan Lindström <jan.lindstrom@mariadb.com>
Date: Thu Dec 1 11:41:27 2016 +0200

MDEV-11168: InnoDB: Failing assertion: !other_lock || wsrep_thd_is_BF(lock->trx->mysql_thd, FALSE) || wsrep_thd_is_BF(other_lock->trx->mysql_thd, FALSE)

Problem was that we moved lock request to head of lock queue
even when lock request has to wait.

Comment by Jan Lindström (Inactive) [ 2016-12-01 ]

http://lists.askmonty.org/pipermail/commits/2016-December/010146.html

Comment by Jan Lindström (Inactive) [ 2016-12-01 ]

http://lists.askmonty.org/pipermail/commits/2016-December/010147.html

Comment by Marko Mäkelä [ 2016-12-01 ]

Looks OK to me. This is related to --innodb-lock-schedule-algorithm=VATS.

Comment by Nirbhay Choubey (Inactive) [ 2016-12-01 ]

jplindst Should we fix this in 10.1 as well?

Comment by Jan Lindström (Inactive) [ 2016-12-02 ]

For 10.1:

commit 2fd3af44830e8df9d60f2e8a955f9ed17e744986
Author: sensssz <hjmsens@gmail.com>
Date: Thu Dec 1 13:45:23 2016 -0500

MDEV-11168: InnoDB: Failing assertion: !other_lock || wsrep_thd_is_BF(lock->trx->mysql_thd, FALSE) || wsrep_thd_is_BF(other_lock->trx->mysql_thd, FALSE)

Merged pull request:
Fix error in lock_has_higher_priority #266
https://github.com/MariaDB/server/pull/266

Added test case.

Comment by Jan Lindström (Inactive) [ 2016-12-02 ]

commit 1e2b46d5d5c0dd4093e2159440cad4b9d7d47ff0
Author: Jan Lindström <jan.lindstrom@mariadb.com>
Date: Fri Dec 2 17:28:39 2016 +0200

MDEV-11168: InnoDB: Failing assertion: !other_lock || wsrep_thd_is_BF(lock->trx->mysql_thd, FALSE) || wsrep_thd_is_BF(other_lock->trx->mysql_thd, FALSE)

Merge fix from 10.1.

Generated at Thu Feb 08 07:47:50 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.