[MDEV-16501] [10.1] InnoDB: Failing assertion: !strcmp(from, s) in dict0mem.cc upon ALTER TABLE with virtual column Created: 2018-06-15  Updated: 2021-06-26  Resolved: 2021-06-26

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Storage Engine - InnoDB, Virtual Columns
Affects Version/s: 10.0, 10.1
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Nikita Malyavin
Resolution: Won't Fix Votes: 0
Labels: not-10.2

Issue Links:
Relates
relates to MDEV-16499 [10.1] ER_NO_SUCH_TABLE_IN_ENGINE fol... Closed
relates to MDEV-16500 Assertion `user_table->n_def > table-... Closed
relates to MDEV-20599 Virtual column: InnoDB: Failing asser... Closed
relates to MDEV-25533 Assertion `!((system_charset_info)->c... Open

 Description   

--source include/have_innodb.inc
CREATE TABLE t1 (a INT, va INT AS (a), b INT) ENGINE=InnoDB;
ALTER TABLE t1 CHANGE COLUMN b c INT;
 
# Cleanup
DROP TABLE t1;

10.1 c22ab56f0d6

2018-06-16 00:17:05 7fba78886b00  InnoDB: Assertion failure in thread 140438862850816 in file dict0mem.cc line 503
InnoDB: Failing assertion: !strcmp(from, s)
 
#5  0x00007fba7681a3fa in abort () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x00007fba6fa77b43 in dict_mem_table_col_rename (table=0x7fba605810f8, nth_col=2, from=0x7fba6cf2df16 "b", to=0x7fba60443780 "c") at /data/src/10.1/storage/innobase/dict/dict0mem.cc:503
#7  0x00007fba6fb19d79 in innobase_rename_columns_cache (ha_alter_info=0x7fba78882b00, table=0x7fba60481c70, user_table=0x7fba605810f8) at /data/src/10.1/storage/innobase/handler/handler0alter.cc:4870
#8  0x00007fba6fb1c0a5 in ha_innodb::commit_inplace_alter_table (this=0x7fba604b0888, altered_table=0x7fba6068f070, ha_alter_info=0x7fba78882b00, commit=true) at /data/src/10.1/storage/innobase/handler/handler0alter.cc:6166
#9  0x00005580582a86eb in handler::ha_commit_inplace_alter_table (this=0x7fba604b0888, altered_table=0x7fba6068f070, ha_alter_info=0x7fba78882b00, commit=true) at /data/src/10.1/sql/handler.cc:4225
#10 0x000055805812524c in mysql_inplace_alter_table (thd=0x7fba6cfc7070, table_list=0x7fba60443180, table=0x7fba60481c70, altered_table=0x7fba6068f070, ha_alter_info=0x7fba78882b00, inplace_supported=HA_ALTER_INPLACE_NO_LOCK_AFTER_PREPARE, target_mdl_request=0x7fba78882b70, alter_ctx=0x7fba78883710) at /data/src/10.1/sql/sql_table.cc:7222
#11 0x0000558058129bbc in mysql_alter_table (thd=0x7fba6cfc7070, new_db=0x7fba60443770 "test", new_name=0x0, create_info=0x7fba78884300, table_list=0x7fba60443180, alter_info=0x7fba78884270, order_num=0, order=0x0, ignore=false) at /data/src/10.1/sql/sql_table.cc:9048
#12 0x000055805819ae35 in Sql_cmd_alter_table::execute (this=0x7fba60443868, thd=0x7fba6cfc7070) at /data/src/10.1/sql/sql_alter.cc:325
#13 0x000055805806a531 in mysql_execute_command (thd=0x7fba6cfc7070) at /data/src/10.1/sql/sql_parse.cc:5696
#14 0x000055805806ecbb in mysql_parse (thd=0x7fba6cfc7070, rawbuf=0x7fba60443088 "ALTER TABLE t1 CHANGE COLUMN b c INT", length=36, parser_state=0x7fba788855e0) at /data/src/10.1/sql/sql_parse.cc:7449
#15 0x000055805805d6f5 in dispatch_command (command=COM_QUERY, thd=0x7fba6cfc7070, packet=0x7fba6eec3071 "ALTER TABLE t1 CHANGE COLUMN b c INT", packet_length=36) at /data/src/10.1/sql/sql_parse.cc:1492
#16 0x000055805805c47a in do_command (thd=0x7fba6cfc7070) at /data/src/10.1/sql/sql_parse.cc:1121
#17 0x00005580581963c7 in do_handle_one_connection (thd_arg=0x7fba6cfc7070) at /data/src/10.1/sql/sql_connect.cc:1330
#18 0x000055805819612b in handle_one_connection (arg=0x7fba6cfc7070) at /data/src/10.1/sql/sql_connect.cc:1242
#19 0x0000558058552af0 in pfs_spawn_thread (arg=0x7fba713f2670) at /data/src/10.1/storage/perfschema/pfs.cc:1861
#20 0x00007fba78515494 in start_thread (arg=0x7fba78886b00) at pthread_create.c:333
#21 0x00007fba768ce93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

No crash on 10.2.
No visible problems on a non-debug build.



 Comments   
Comment by Marko Mäkelä [ 2018-08-29 ]

Before 10.2, InnoDB does not know about virtual columns.

serg, could it be that the virtual columns are not passed to ha_innobase::create(), but they are being passed to ha_innobase::inplace_alter_table() and friends?

What would be the better fix? Filter out the virtual columns before passing the TABLE_SHARE objects to ALGORITHM=INPLACE, or modify InnoDB in 10.0 and 10.1 to ignore the virtual columns?

Comment by Nikita Malyavin [ 2019-09-09 ]

marko I think if the engine is not aware of virtual columns, they shouldn't be passed

Comment by Nikita Malyavin [ 2021-06-26 ]

should we close this task?

Comment by Elena Stepanova [ 2021-06-26 ]

Closing as "won't fix" since 10.1 has reached EOL, and higher versions are not affected.

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