[MDEV-24381] Assertion `user_table->get_ref_count() == 1' failed in commit_try_rebuild Created: 2020-12-09  Updated: 2023-04-27

Status: Open
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Storage Engine - InnoDB
Affects Version/s: 10.2, 10.3, 10.4
Fix Version/s: 10.4

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


 Description   

10.2 a3f7f233

mysqld: /data/src/10.2/storage/innobase/handler/handler0alter.cc:7589: bool commit_try_rebuild(Alter_inplace_info*, ha_innobase_inplace_ctx*, TABLE*, const TABLE*, trx_t*, const char*): Assertion `user_table->get_ref_count() == 1' failed.
201209 20:48:50 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f0cfcfd5f36 in __GI___assert_fail (assertion=0x55ba676f1510 "user_table->get_ref_count() == 1", file=0x55ba676eee28 "/data/src/10.2/storage/innobase/handler/handler0alter.cc", line=7589, function=0x55ba676f2d80 "bool commit_try_rebuild(Alter_inplace_info*, ha_innobase_inplace_ctx*, TABLE*, const TABLE*, trx_t*, const char*)") at assert.c:101
#8  0x000055ba670251a4 in commit_try_rebuild (ha_alter_info=0x7f0cf33ec030, ctx=0x7f0ca4012a98, altered_table=0x7f0ca402c620, old_table=0x7f0ca406d690, trx=0x7f0cf8010330, table_name=0x7f0ca406cd2d "t2") at /data/src/10.2/storage/innobase/handler/handler0alter.cc:7589
#9  0x000055ba670218d4 in ha_innobase::commit_inplace_alter_table (this=0x7f0ca4066ef8, altered_table=0x7f0ca402c620, ha_alter_info=0x7f0cf33ec030, commit=true) at /data/src/10.2/storage/innobase/handler/handler0alter.cc:8437
#10 0x000055ba66ddf1e0 in handler::ha_commit_inplace_alter_table (this=0x7f0ca4066ef8, altered_table=0x7f0ca402c620, ha_alter_info=0x7f0cf33ec030, commit=true) at /data/src/10.2/sql/handler.cc:4378
#11 0x000055ba66c27865 in mysql_inplace_alter_table (thd=0x7f0ca4000d90, table_list=0x7f0ca4011420, table=0x7f0ca406d690, altered_table=0x7f0ca402c620, ha_alter_info=0x7f0cf33ec030, inplace_supported=HA_ALTER_INPLACE_NO_LOCK_AFTER_PREPARE, target_mdl_request=0x7f0cf33ec0c0, alter_ctx=0x7f0cf33ec670) at /data/src/10.2/sql/sql_table.cc:7480
#12 0x000055ba66c2d5a5 in mysql_alter_table (thd=0x7f0ca4000d90, new_db=0x7f0ca4011a38 "test", new_name=0x0, create_info=0x7f0cf33ed290, table_list=0x7f0ca4011420, alter_info=0x7f0cf33ed1e0, order_num=0, order=0x0, ignore=false) at /data/src/10.2/sql/sql_table.cc:9622
#13 0x000055ba66cab91c in Sql_cmd_alter_table::execute (this=0x7f0ca4011b00, thd=0x7f0ca4000d90) at /data/src/10.2/sql/sql_alter.cc:333
#14 0x000055ba66b5a222 in mysql_execute_command (thd=0x7f0ca4000d90) at /data/src/10.2/sql/sql_parse.cc:5993
#15 0x000055ba66b5f239 in mysql_parse (thd=0x7f0ca4000d90, rawbuf=0x7f0ca4011338 "ALTER TABLE t2 ADD UNIQUE (b)", length=29, parser_state=0x7f0cf33ee5f0, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7762
#16 0x000055ba66b4d532 in dispatch_command (command=COM_QUERY, thd=0x7f0ca4000d90, packet=0x7f0ca4008b51 "ALTER TABLE t2 ADD UNIQUE (b)", packet_length=29, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1827
#17 0x000055ba66b4c02d in do_command (thd=0x7f0ca4000d90) at /data/src/10.2/sql/sql_parse.cc:1381
#18 0x000055ba66ca6311 in do_handle_one_connection (connect=0x55ba6ab0abd0) at /data/src/10.2/sql/sql_connect.cc:1336
#19 0x000055ba66ca6076 in handle_one_connection (arg=0x55ba6ab0abd0) at /data/src/10.2/sql/sql_connect.cc:1241
#20 0x000055ba674cda9c in pfs_spawn_thread (arg=0x55ba6ab4b590) at /data/src/10.2/storage/perfschema/pfs.cc:1869
#21 0x00007f0cfd4e5609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#22 0x00007f0cfd0c1293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Non-deterministic test case, run with --repeat=N. It fails for me in several attempts, but it can vary on different machines and builds.

--source include/have_innodb.inc
--source include/have_partition.inc
 
call mtr.add_suppression("has or is referenced in foreign key constraints which are not compatible");
 
CREATE TABLE t1 (pk INT PRIMARY KEY, a INT) ENGINE=InnoDB;
INSERT INTO t1 VALUES (1,10);
 
CREATE TABLE t2 (id BIGINT, b TIMESTAMP, KEY(id)) ENGINE=InnoDB PARTITION BY KEY(id) PARTITIONS 2;
 
SET FOREIGN_KEY_CHECKS= OFF;
ALTER TABLE t1 ADD FOREIGN KEY (a) REFERENCES t2 (id);
 
--connect (con1,localhost,root,,test)
 
SET FOREIGN_KEY_CHECKS= OFF;
ALTER TABLE t2 REMOVE PARTITIONING;
--send
  ALTER TABLE t2 ADD UNIQUE (b);
 
--connection default
UPDATE IGNORE t1 SET a = 0;
 
# Cleanup
--connection con1
--reap
--disconnect con1
--connection default
DROP TABLE t1, t2;

Reproducible on 10.2-10.4 debug builds. Couldn't reproduce on 10.5 so far.
No obvious problem observed on a non-debug build.
Could not reproduce with rr.


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