[MDEV-23240] Assertion `!table->is_temporary()' failed 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: rr-profile

Issue Links:
Relates
relates to MDEV-15880 Server crash or ASAN heap-use-after-f... Closed
relates to MDEV-23241 Assertion `lock->trx->dict_operation ... Closed
relates to MDEV-23239 InnoDB: Failing assertion: ((list).in... Closed

 Description   

The test case is exactly the same as in MDEV-23239, and the same disclaimer applies: if the variable innodb_evict_tables_on_commit_debug shouldn't be used in such scenario, feel free to close.

The difference with MDEV-23239 is that if this test case is run with performance-schema=off on 10.5, it causes the assertion failure below, different from the one in MDEV-23239. Of course, it can still have the same root cause.

--source include/have_innodb.inc
 
--source include/have_log_bin.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.5 054f1036

 
mariadbd: /data/src/10.5/storage/innobase/lock/lock0lock.cc:4238: void lock_check_dict_lock(const ib_lock_t*): Assertion `!table->is_temporary()' failed.
 
200721  0:57:47 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007f0d06418f12 in __GI___assert_fail (assertion=0x5602de99a6be "!table->is_temporary()", file=0x5602de999308 "/data/src/10.5/storage/innobase/lock/lock0lock.cc", line=4238, function=0x5602de99f2e0 <lock_check_dict_lock(ib_lock_t const*)::__PRETTY_FUNCTION__> "void lock_check_dict_lock(const ib_lock_t*)") at assert.c:101
 
#8  0x00005602de13f70c in lock_check_dict_lock (lock=0x7f0d04d56060) at /data/src/10.5/storage/innobase/lock/lock0lock.cc:4238
 
#9  0x00005602de13f8c3 in lock_release (trx=0x7f0d04d553c0) at /data/src/10.5/storage/innobase/lock/lock0lock.cc:4267
 
#10 0x00005602de30d966 in trx_t::release_locks (this=0x7f0d04d553c0) at /data/src/10.5/storage/innobase/trx/trx0trx.cc:514
 
#11 0x00005602de30e0a1 in trx_t::commit_in_memory (this=0x7f0d04d553c0, mtr=0x0) at /data/src/10.5/storage/innobase/trx/trx0trx.cc:1374
 
#12 0x00005602de309b8a in trx_t::commit_low (this=0x7f0d04d553c0, mtr=0x0) at /data/src/10.5/storage/innobase/trx/trx0trx.cc:1563
 
#13 0x00005602de309c17 in trx_t::commit (this=0x7f0d04d553c0) at /data/src/10.5/storage/innobase/trx/trx0trx.cc:1577
 
#14 0x00005602de30a115 in trx_commit_for_mysql (trx=0x7f0d04d553c0) at /data/src/10.5/storage/innobase/trx/trx0trx.cc:1709
 
#15 0x00005602de07ee38 in innobase_commit_low (trx=0x7f0d04d553c0) at /data/src/10.5/storage/innobase/handler/ha_innodb.cc:4121
 
#16 0x00005602de07f245 in innobase_commit_ordered_2 (trx=0x7f0d04d553c0, thd=0x7f0ccc000b18) at /data/src/10.5/storage/innobase/handler/ha_innodb.cc:4250
 
#17 0x00005602de07f888 in innobase_commit (hton=0x5602e19a4108, thd=0x7f0ccc000b18, commit_trx=true) at /data/src/10.5/storage/innobase/handler/ha_innodb.cc:4367
 
#18 0x00005602ddc26bdf in commit_one_phase_2 (thd=0x7f0ccc000b18, all=true, trans=0x7f0ccc004100, is_real_trans=true) at /data/src/10.5/sql/handler.cc:1936
 
#19 0x00005602ddc26adb in ha_commit_one_phase (thd=0x7f0ccc000b18, all=true) at /data/src/10.5/sql/handler.cc:1916
 
#20 0x00005602ddc25c4c in ha_commit_trans (thd=0x7f0ccc000b18, all=true) at /data/src/10.5/sql/handler.cc:1716
 
#21 0x00005602dda85003 in trans_commit_implicit (thd=0x7f0ccc000b18) at /data/src/10.5/sql/transaction.cc:329
 
#22 0x00005602dd8cc0b3 in mysql_execute_command (thd=0x7f0ccc000b18) at /data/src/10.5/sql/sql_parse.cc:3741
 
#23 0x00005602dd8da379 in mysql_parse (thd=0x7f0ccc000b18, rawbuf=0x7f0ccc0139f0 "DROP TABLE t_error_prone", length=24, parser_state=0x7f0d0425a520, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:7993
 
#24 0x00005602dd8c6672 in dispatch_command (command=COM_QUERY, thd=0x7f0ccc000b18, packet=0x7f0ccc170389 "DROP TABLE t_error_prone", packet_length=24, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1867
 
#25 0x00005602dd8c4daa in do_command (thd=0x7f0ccc000b18) at /data/src/10.5/sql/sql_parse.cc:1348
 
#26 0x00005602dda6a589 in do_handle_one_connection (connect=0x5602e1ce9c98, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1411
 
#27 0x00005602dda6a2f1 in handle_one_connection (arg=0x5602e1ce9c98) at /data/src/10.5/sql/sql_connect.cc:1313
 
#28 0x00005602ddfa83f6 in pfs_spawn_thread (arg=0x5602e1cb36f8) at /data/src/10.5/storage/perfschema/pfs.cc:2201
 
#29 0x00007f0d083a14a4 in start_thread (arg=0x7f0d0425b700) at pthread_create.c:456
 
#30 0x00007f0d064d5d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Couldn't reproduce with the test case above on 10.4, because it fails with MDEV-23239 instead (regardless the value of --performance-schema. However, the failure has been observed on 10.4 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-23241

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