[MDEV-16500] Assertion `user_table->n_def > table->s->fields' failed in innobase_get_col_names upon ALTER TABLE with virtual columns Created: 2018-06-15  Updated: 2021-04-30  Resolved: 2021-04-30

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: Sergei Golubchik
Resolution: Won't Fix Votes: 0
Labels: affects-tests

Issue Links:
Relates
relates to MDEV-16499 [10.1] ER_NO_SUCH_TABLE_IN_ENGINE fol... Closed
relates to MDEV-16501 [10.1] InnoDB: Failing assertion: !st... Closed

 Description    

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

10.1 c22ab56f0

 
mysqld: /data/src/10.1/storage/innobase/handler/handler0alter.cc:2649: const char** innobase_get_col_names(Alter_inplace_info*, const TABLE*, const TABLE*, const dict_table_t*, mem_heap_t*): Assertion `user_table->n_def > table->s->fields' failed.
 
180616  0:09:49 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007f4be012fee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
 
#8  0x00007f4bd9713c0a in innobase_get_col_names (ha_alter_info=0x7f4be21a0b00, altered_table=0x7f4bca28d070, table=0x7f4bca081c70, user_table=0x7f4bdaff2678, heap=0x7f4bca0a3700) at /data/src/10.1/storage/innobase/handler/handler0alter.cc:2649
 
#9  0x00007f4bd9717306 in ha_innodb::prepare_inplace_alter_table (this=0x7f4bca0b0888, altered_table=0x7f4bca28d070, ha_alter_info=0x7f4be21a0b00) at /data/src/10.1/storage/innobase/handler/handler0alter.cc:3766
 
#10 0x000055eb3c4fe62f in handler::ha_prepare_inplace_alter_table (this=0x7f4bca0b0888, altered_table=0x7f4bca28d070, ha_alter_info=0x7f4be21a0b00) at /data/src/10.1/sql/handler.cc:4205
 
#11 0x000055eb3c37afec in mysql_inplace_alter_table (thd=0x7f4bd6bc7070, table_list=0x7f4bca043180, table=0x7f4bca081c70, altered_table=0x7f4bca28d070, ha_alter_info=0x7f4be21a0b00, inplace_supported=HA_ALTER_INPLACE_NO_LOCK_AFTER_PREPARE, target_mdl_request=0x7f4be21a0b70, alter_ctx=0x7f4be21a1710) at /data/src/10.1/sql/sql_table.cc:7164
 
#12 0x000055eb3c37fbbc in mysql_alter_table (thd=0x7f4bd6bc7070, new_db=0x7f4bca043770 "test", new_name=0x0, create_info=0x7f4be21a2300, table_list=0x7f4bca043180, alter_info=0x7f4be21a2270, order_num=0, order=0x0, ignore=false) at /data/src/10.1/sql/sql_table.cc:9048
 
#13 0x000055eb3c3f0e35 in Sql_cmd_alter_table::execute (this=0x7f4bca043868, thd=0x7f4bd6bc7070) at /data/src/10.1/sql/sql_alter.cc:325
 
#14 0x000055eb3c2c0531 in mysql_execute_command (thd=0x7f4bd6bc7070) at /data/src/10.1/sql/sql_parse.cc:5696
 
#15 0x000055eb3c2c4cbb in mysql_parse (thd=0x7f4bd6bc7070, rawbuf=0x7f4bca043088 "ALTER TABLE t1 CHANGE COLUMN d e INT", length=36, parser_state=0x7f4be21a35e0) at /data/src/10.1/sql/sql_parse.cc:7449
 
#16 0x000055eb3c2b36f5 in dispatch_command (command=COM_QUERY, thd=0x7f4bd6bc7070, packet=0x7f4bd8ac3071 "ALTER TABLE t1 CHANGE COLUMN d e INT", packet_length=36) at /data/src/10.1/sql/sql_parse.cc:1492
 
#17 0x000055eb3c2b247a in do_command (thd=0x7f4bd6bc7070) at /data/src/10.1/sql/sql_parse.cc:1121
 
#18 0x000055eb3c3ec3c7 in do_handle_one_connection (thd_arg=0x7f4bd6bc7070) at /data/src/10.1/sql/sql_connect.cc:1330
 
#19 0x000055eb3c3ec12b in handle_one_connection (arg=0x7f4bd6bc7070) at /data/src/10.1/sql/sql_connect.cc:1242
 
#20 0x000055eb3c7a8af0 in pfs_spawn_thread (arg=0x7f4bdaff2670) at /data/src/10.1/storage/perfschema/pfs.cc:1861
 
#21 0x00007f4be1e33494 in start_thread (arg=0x7f4be21a4b00) at pthread_create.c:333
 
#22 0x00007f4be01ec93f 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 ]

The assertion is bogus, because table->s->fields counts the virtual columns as well, but user_table->n_def only contains persistent columns, including the 3 hidden InnoDB system columns DB_ROW_ID,DB_TRX_ID,DB_ROLL_PTR at the end of the table row tuple.

In 10.2 the InnoDB data structures were refined, and the assertion would refer to user_table->n_t_def which counts all user-defined columns, including virtual ones.
serg, I think we should replace table->s->fields in the assertion with something that only counts the persistent columns. But, I see that create_table_def() in 10.0 is using table->s->fields directly. Maybe the problem is that TABLE_SHARE::fields is initialized differently during ALTER TABLE than it is during CREATE TABLE. Maybe the virtual columns were added to the count after handler::ha_create() returned?

Comment by Elena Stepanova [ 2021-04-30 ]

Since 10.1 is now EOL and 10.2+ aren't affected, closing as "won't fix".

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