[MDEV-23241] Assertion `lock->trx->dict_operation != TRX_DICT_OP_NONE' in lock_check_dict_lock with innodb_evict_tables_on_commit_debug Created: 2020-07-20  Updated: 2020-07-21  Resolved: 2020-07-21

Status: Closed
Project: MariaDB Server
Component/s: Debug, Storage Engine - InnoDB
Affects Version/s: 10.4, 10.5
Fix Version/s: 10.4.14, 10.5.5

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Marko Mäkelä
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-15880 Server crash or ASAN heap-use-after-f... Closed
relates to MDEV-23239 InnoDB: Failing assertion: ((list).in... Closed
relates to MDEV-23240 Assertion `!table->is_temporary()' fa... Closed

 Description   

The test case is almost exactly the same as in MDEV-23239, except that MDEV-23239 has binary logging enabled, and this one does not. The same disclaimer applies: if the variable innodb_evict_tables_on_commit_debug shouldn't be used in such scenario, feel free to close.

--source include/have_innodb.inc
 
SET @innodb_var.save= @@innodb_evict_tables_on_commit_debug;
 
--connect (con1,localhost,root,,test)
CREATE TABLE t_error_prone (f INT) ENGINE=InnoDB;
 
--connection default
INSERT INTO t_error_prone (f) VALUES (1);
 
--connection con1
START TRANSACTION;
UPDATE t_error_prone SET f = 2;
 
--connection default
SET innodb_lock_wait_timeout= 0;
START TRANSACTION;
--error ER_LOCK_WAIT_TIMEOUT
UPDATE t_error_prone SET f = NULL;
 
--connect (con2,localhost,root,,test)
FLUSH TABLES;
SET GLOBAL innodb_evict_tables_on_commit_debug= 1;
 
--connection con1
--error ER_NO_SUCH_TABLE
ALTER TABLE x FORCE;
 
--connection default
DROP TABLE t_error_prone;
 
# Cleanup
--disconnect con1
--disconnect con2
SET GLOBAL innodb_evict_tables_on_commit_debug= @innodb_var.save;

10.4 956f21c3

mysqld: /data/src/10.4/storage/innobase/lock/lock0lock.cc:4266: void lock_check_dict_lock(const ib_lock_t*): Assertion `lock->trx->dict_operation != TRX_DICT_OP_NONE' failed.
200721  1:10:50 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f0e4fc57f12 in __GI___assert_fail (assertion=0x55ff9a2dcd40 "lock->trx->dict_operation != TRX_DICT_OP_NONE", file=0x55ff9a2db558 "/data/src/10.4/storage/innobase/lock/lock0lock.cc", line=4266, function=0x55ff9a2e1980 <lock_check_dict_lock(ib_lock_t const*)::__PRETTY_FUNCTION__> "void lock_check_dict_lock(const ib_lock_t*)") at assert.c:101
#8  0x000055ff999fcd5e in lock_check_dict_lock (lock=0x7f0e49a9ae58) at /data/src/10.4/storage/innobase/lock/lock0lock.cc:4266
#9  0x000055ff999fce58 in lock_release (trx=0x7f0e49a9a268) at /data/src/10.4/storage/innobase/lock/lock0lock.cc:4286
#10 0x000055ff99bc78b6 in trx_t::release_locks (this=0x7f0e49a9a268) at /data/src/10.4/storage/innobase/trx/trx0trx.cc:512
#11 0x000055ff99bc7ff1 in trx_t::commit_in_memory (this=0x7f0e49a9a268, mtr=0x0) at /data/src/10.4/storage/innobase/trx/trx0trx.cc:1390
#12 0x000055ff99bc3d22 in trx_t::commit_low (this=0x7f0e49a9a268, mtr=0x0) at /data/src/10.4/storage/innobase/trx/trx0trx.cc:1579
#13 0x000055ff99bc3daf in trx_t::commit (this=0x7f0e49a9a268) at /data/src/10.4/storage/innobase/trx/trx0trx.cc:1593
#14 0x000055ff99bc4261 in trx_commit_for_mysql (trx=0x7f0e49a9a268) at /data/src/10.4/storage/innobase/trx/trx0trx.cc:1725
#15 0x000055ff99944c14 in innobase_commit_low (trx=0x7f0e49a9a268) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:4348
#16 0x000055ff99945025 in innobase_commit_ordered_2 (trx=0x7f0e49a9a268, thd=0x7f0dfc000af0) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:4477
#17 0x000055ff99945659 in innobase_commit (hton=0x55ff9c08f160, thd=0x7f0dfc000af0, commit_trx=true) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:4593
#18 0x000055ff99701b60 in commit_one_phase_2 (thd=0x7f0dfc000af0, all=true, trans=0x7f0dfc004088, is_real_trans=true) at /data/src/10.4/sql/handler.cc:1776
#19 0x000055ff99701a5c in ha_commit_one_phase (thd=0x7f0dfc000af0, all=true) at /data/src/10.4/sql/handler.cc:1756
#20 0x000055ff99700cd0 in ha_commit_trans (thd=0x7f0dfc000af0, all=true) at /data/src/10.4/sql/handler.cc:1564
#21 0x000055ff99540fa9 in trans_commit_implicit (thd=0x7f0dfc000af0) at /data/src/10.4/sql/transaction.cc:301
#22 0x000055ff993a679e in mysql_execute_command (thd=0x7f0dfc000af0) at /data/src/10.4/sql/sql_parse.cc:3700
#23 0x000055ff993b482f in mysql_parse (thd=0x7f0dfc000af0, rawbuf=0x7f0dfc013198 "DROP TABLE t_error_prone", length=24, parser_state=0x7f0e49000570, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7899
#24 0x000055ff993a0d64 in dispatch_command (command=COM_QUERY, thd=0x7f0dfc000af0, packet=0x7f0dfc0083a1 "DROP TABLE t_error_prone", packet_length=24, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1834
#25 0x000055ff9939f506 in do_command (thd=0x7f0dfc000af0) at /data/src/10.4/sql/sql_parse.cc:1352
#26 0x000055ff995285c4 in do_handle_one_connection (connect=0x55ff9c350d20) at /data/src/10.4/sql/sql_connect.cc:1412
#27 0x000055ff99528313 in handle_one_connection (arg=0x55ff9c350d20) at /data/src/10.4/sql/sql_connect.cc:1316
#28 0x000055ff99f27c93 in pfs_spawn_thread (arg=0x55ff9c36cc80) at /data/src/10.4/storage/perfschema/pfs.cc:1869
#29 0x00007f0e51be04a4 in start_thread (arg=0x7f0e49001700) at pthread_create.c:456
#30 0x00007f0e4fd14d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Couldn't reproduce with the provided test case on 10.3 (it fails with MDEV-23239 instead), or on 10.5 (it doesn't fail); however, the assertion failure as been observed on 10.5 in concurrent tests.



 Comments   
Comment by Elena Stepanova [ 2020-07-21 ]

It appears to have been addressed by the same patch that fixes MDEV-15880, MDEV-23239 and MDEV-23240

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