[MDEV-18696] Assertion `newtrn->used_instances != (void*) tbl' failed in _ma_set_trn_for_table Created: 2019-02-22  Updated: 2020-09-17  Resolved: 2020-09-17

Status: Closed
Project: MariaDB Server
Component/s: Locking, Storage Engine - Aria
Affects Version/s: 10.3
Fix Version/s: 10.3.18, 10.4.8, 10.5.0

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: not-10.4

Issue Links:
Relates
relates to MDEV-18154 Deadlock and assertion upon no-op ALT... Closed

 Description   

--source include/have_partition.inc
 
CREATE TABLE t1 (a INT) ENGINE=Aria ;
CREATE TABLE t2 (
  pk INT,
  b CHAR(255) CHARACTER SET utf8,
  c VARCHAR(255) CHARACTER SET utf8,
  PRIMARY KEY (pk)
) ENGINE=Aria PARTITION BY key (pk) partitions 2;
CREATE OR REPLACE VIEW v2 AS SELECT * FROM t2 ;
INSERT IGNORE INTO t2 VALUES (1,'foo','bar'),(2,'qux','foobar');
LOCK TABLES v2 WRITE CONCURRENT, t1 WRITE CONCURRENT, t2 WRITE;
ALTER IGNORE TABLE t2 CHANGE COLUMN IF EXISTS f1 f2 INT;
 
# Cleanup
UNLOCK TABLES;
DROP VIEW v2;
DROP TABLE t1, t2;

10.3 non-ASAN debug 4946eb7b

mysqld: /data/src/10.3/storage/maria/ma_trnman.h:33: void _ma_set_trn_for_table(MARIA_HA*, TRN*): Assertion `newtrn->used_instances != (void*) tbl' failed.
190222 20:13:22 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f06c96f2ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x0000561cec6a1f7b in _ma_set_trn_for_table (tbl=0x7f06a80ac180, newtrn=0x7f06a804ca50) at /data/src/10.3/storage/maria/ma_trnman.h:33
#9  0x0000561cec6a453f in maria_create_trn_for_mysql (info=0x7f06a80ac180) at /data/src/10.3/storage/maria/ha_maria.cc:937
#10 0x0000561cec6930a7 in _ma_setup_live_state (info=0x7f06a80ac180) at /data/src/10.3/storage/maria/ma_state.c:65
#11 0x0000561cec694573 in _ma_block_start_trans (param=0x7f06a80ac180) at /data/src/10.3/storage/maria/ma_state.c:680
#12 0x0000561cecc43865 in thr_multi_lock (data=0x7f06a8175810, count=2, owner=0x7f06a8002600, lock_wait_timeout=31536000) at /data/src/10.3/mysys/thr_lock.c:1318
#13 0x0000561cec5c026d in mysql_lock_tables (thd=0x7f06a8000b00, sql_lock=0x7f06a81757e0, flags=18539) at /data/src/10.3/sql/lock.cc:355
#14 0x0000561cec5c006e in mysql_lock_tables (thd=0x7f06a8000b00, tables=0x7f06a80b46f8, count=1, flags=18539) at /data/src/10.3/sql/lock.cc:304
#15 0x0000561cec10c417 in Locked_tables_list::reopen_tables (this=0x7f06a8004800, thd=0x7f06a8000b00, need_reopen=true) at /data/src/10.3/sql/sql_base.cc:2521
#16 0x0000561cec1a4af9 in mysql_execute_command (thd=0x7f06a8000b00) at /data/src/10.3/sql/sql_parse.cc:6318
#17 0x0000561cec1a9a69 in mysql_parse (thd=0x7f06a8000b00, rawbuf=0x7f06a8014ce8 "ALTER IGNORE TABLE t2 CHANGE COLUMN IF EXISTS f1 f2 INT", length=55, parser_state=0x7f06c409a5f0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:8095
#18 0x0000561cec196c1d in dispatch_command (command=COM_QUERY, thd=0x7f06a8000b00, packet=0x7f06a800b1f1 "ALTER IGNORE TABLE t2 CHANGE COLUMN IF EXISTS f1 f2 INT", packet_length=55, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1854
#19 0x0000561cec1955f5 in do_command (thd=0x7f06a8000b00) at /data/src/10.3/sql/sql_parse.cc:1396
#20 0x0000561cec2fdd07 in do_handle_one_connection (connect=0x561cefb64f80) at /data/src/10.3/sql/sql_connect.cc:1403
#21 0x0000561cec2fda8b in handle_one_connection (arg=0x561cefb64f80) at /data/src/10.3/sql/sql_connect.cc:1309
#22 0x0000561cec799c1f in pfs_spawn_thread (arg=0x561cefb6d670) at /data/src/10.3/storage/perfschema/pfs.cc:1862
#23 0x00007f06cb3c9494 in start_thread (arg=0x7f06c409b700) at pthread_create.c:333
#24 0x00007f06c97af93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

No visible effect on a non-debug build and, strangely, on a debug ASAN build.
Not reproducible on 10.4.
10.2 crashes with MDEV-10748 instead.



 Comments   
Comment by Elena Stepanova [ 2020-06-27 ]

Not reproducible on the current 10.3. It's not very surprising, there have been numerous Aria-related fixed, but I want to find the fixing commit before closing it.

Comment by Elena Stepanova [ 2020-09-17 ]

The failure disappeared from 10.3 branch after this commit:

commit 1639873671e85748f0dcf89ce76ef4efce9a087c
Author: Aleksey Midenkov <midenok@gmail.com>
Date:   Thu Aug 15 22:32:59 2019 +0300
 
    MDEV-18154 Deadlock and assertion upon no-op ALTER under LOCK TABLES

There are similarities in the test cases, so I assume the patch for MDEV-18154 indeed fixed both.

Generated at Thu Feb 08 08:46:03 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.