[MDEV-17199] Assertion `pos < table->n_v_def' failed in dict_table_get_nth_v_col after upgrade from 10.1/10.0 to 10.2 Created: 2018-09-14  Updated: 2019-03-19  Resolved: 2018-12-20

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Virtual Columns
Affects Version/s: 10.2, 10.3
Fix Version/s: 10.2.20, 10.3.12

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Fixed Votes: 1
Labels: affects-tests

Attachments: File data.tar.gz    
Issue Links:
Blocks
blocks MDEV-14046 Allow ALGORITHM=INPLACE for 10.1 tabl... Closed
blocks MDEV-17498 MariaDB 10.2.18 mysqld got signal 11 ... Closed
Problem/Incident
causes MDEV-18084 Server crashes in row_upd_changes_som... Closed
Relates
relates to MDEV-12936 upgrade to 10.2.6 failed upon tables ... Closed
relates to MDEV-17909 Problem by MariaDB Update 10.1.32 -> ... Closed
relates to MDEV-18960 Assertion `!omits_virtual_cols(*form-... Closed

 Description   

10.2 c3124174c3e

 
mysqld: /data/src/10.2/storage/innobase/include/dict0dict.ic:490: dict_v_col_t* dict_table_get_nth_v_col(const dict_table_t*, ulint): Assertion `pos < table->n_v_def' failed.
 
180914 17:10:31 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007f1741e79ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
 
#8  0x000055f0f51c6701 in dict_table_get_nth_v_col (table=0x7f16d400c6c8, pos=0) at /data/src/10.2/storage/innobase/include/dict0dict.ic:490
 
#9  0x000055f0f51d36d6 in build_template_field (prebuilt=0x7f16d402c508, clust_index=0x7f16d4035578, index=0x7f16d4035578, table=0x7f16d4020920, field=0x7f16d400b648, i=0, v_no=0) at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:7511
 
#10 0x000055f0f51d5299 in ha_innobase::build_template (this=0x7f16d4021528, whole_row=true) at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:8010
 
#11 0x000055f0f51e280b in ha_innobase::check (this=0x7f16d4021528, thd=0x7f16d4000b00, check_opt=0x7f16d40055e8) at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:14590
 
#12 0x000055f0f4ec6d39 in handler::ha_check (this=0x7f16d4021528, thd=0x7f16d4000b00, check_opt=0x7f16d40055e8) at /data/src/10.2/sql/handler.cc:3973
 
#13 0x000055f0f4da5dad in mysql_admin_table(THD *, TABLE_LIST *, HA_CHECK_OPT *, const char *, thr_lock_type, bool, bool, uint, int (*)(THD *, TABLE_LIST *, HA_CHECK_OPT *), struct {...}, int (*)(THD *, TABLE_LIST *, HA_CHECK_OPT *)) (thd=0x7f16d4000b00, tables=0x7f16d40111d0, check_opt=0x7f16d40055e8, operator_name=0x55f0f570d25c "check", lock_type=TL_READ_NO_INSERT, org_open_for_modify=false, repair_table_use_frm=false, extra_open_options=32, prepare_func=0x0, operator_func=(int (handler::*)(handler * const, THD *, HA_CHECK_OPT *)) 0x55f0f4ec6c14 <handler::ha_check(THD*, st_ha_check_opt*)>, view_operator_func=0x55f0f4d412d5 <view_check(THD*, TABLE_LIST*, st_ha_check_opt*)>) at /data/src/10.2/sql/sql_admin.cc:798
 
#14 0x000055f0f4da7f5e in Sql_cmd_check_table::execute (this=0x7f16d40117e0, thd=0x7f16d4000b00) at /data/src/10.2/sql/sql_admin.cc:1343
 
#15 0x000055f0f4c50dd2 in mysql_execute_command (thd=0x7f16d4000b00) at /data/src/10.2/sql/sql_parse.cc:6225
 
#16 0x000055f0f4c55bbe in mysql_parse (thd=0x7f16d4000b00, rawbuf=0x7f16d40110f8 "check table test.t1", length=19, parser_state=0x7f174014c250, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:8009
 
#17 0x000055f0f4c4363c in dispatch_command (command=COM_QUERY, thd=0x7f16d4000b00, packet=0x7f16d40191e1 "", packet_length=19, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1824
 
#18 0x000055f0f4c41f9f in do_command (thd=0x7f16d4000b00) at /data/src/10.2/sql/sql_parse.cc:1378
 
#19 0x000055f0f4d939ae in do_handle_one_connection (connect=0x55f0f9224940) at /data/src/10.2/sql/sql_connect.cc:1335
 
#20 0x000055f0f4d9373b in handle_one_connection (arg=0x55f0f9224940) at /data/src/10.2/sql/sql_connect.cc:1241
 
#21 0x00007f1743b50494 in start_thread (arg=0x7f174014d700) at pthread_create.c:333
 
#22 0x00007f1741f3693f in clone () from /lib/x86_64-linux-gnu/libc.so.6

An example of 10.1 datadir is attached (state of the datadir after normal shutdown on 10.1, before any attempt to run 10.2 on it): data.tar.gz

  • start 10.2 on the datadir, all default options should be sufficient;
  • run CHECK TABLE test.t1

The problem blocks testing of changes made in the scope of MDEV-14046.

 Comments   
Comment by Elena Stepanova [ 2018-09-14 ]

marko thinks it's related to MDEV-12936.

Comment by Elena Stepanova [ 2018-09-17 ]

On bb-10.2-marko 5897e4d2c2247f0aee3757dc0607b147d827a118 where the assertion above is fixed, I get SIGSEGV instead:

#3  <signal handler called>
 
#4  0x0000564a43b573f3 in unpack_vcol_info_from_frm (thd=0x7f68fc009c00, mem_root=0x7f69466f1d48, table=0x7f69466f1290, expr_str=0x7f69466f0da0, vcol_ptr=0x7f68fc8c4d80, error_reported=0x7f69466f1139) at /home/travis/src/sql/table.cc:2936
 
#5  0x0000564a43b50cea in parse_vcol_defs (thd=0x7f68fc009c00, mem_root=0x7f69466f1d48, table=0x7f69466f1290, error_reported=0x7f69466f1139) at /home/travis/src/sql/table.cc:1069
 
#6  0x0000564a43b58201 in open_table_from_share (thd=0x7f68fc009c00, share=0x7f68e4115078, alias=0x7f68fc8d31a8 "t3", db_stat=0, prgflag=32776, ha_open_flags=16, outparam=0x7f69466f1290, is_create_table=false) at /home/travis/src/sql/table.cc:3189
 
#7  0x0000564a43aefc62 in fill_schema_table_from_frm (thd=0x7f68fc009c00, table=0x7f68fc46f578, schema_table=0x564a44dd0a60 <schema_tables+320>, db_name=0x7f68fc7d05a0, table_name=0x7f68fc8d3198, open_tables_state_backup=0x7f69466f2740, can_deadlock=false) at /home/travis/src/sql/sql_show.cc:4749
 
#8  0x0000564a43af0674 in get_all_tables (thd=0x7f68fc009c00, tables=0x7f68fc32a868, cond=0x7f68fc2b90b0) at /home/travis/src/sql/sql_show.cc:4996
 
#9  0x0000564a43b00622 in get_schema_tables_result (join=0x7f68fc259bc0, executed_place=PROCESSED_BY_JOIN_EXEC) at /home/travis/src/sql/sql_show.cc:8350
 
#10 0x0000564a43a9d311 in JOIN::exec_inner (this=0x7f68fc259bc0) at /home/travis/src/sql/sql_select.cc:3573
 
#11 0x0000564a43a9c9cc in JOIN::exec (this=0x7f68fc259bc0) at /home/travis/src/sql/sql_select.cc:3404
 
#12 0x0000564a43a9dbca in mysql_select (thd=0x7f68fc009c00, tables=0x7f68fc32a1f8, wild_num=0, fields=..., conds=0x7f68fc32c570, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2684619521, result=0x7f68fc259ba0, unit=0x7f68fc00d7e0, select_lex=0x7f68fc00df18) at /home/travis/src/sql/sql_select.cc:3804
 
#13 0x0000564a43a91e6e in handle_select (thd=0x7f68fc009c00, lex=0x7f68fc00d718, result=0x7f68fc259ba0, setup_tables_done_option=0) at /home/travis/src/sql/sql_select.cc:376
 
#14 0x0000564a43a5d433 in execute_sqlcom_select (thd=0x7f68fc009c00, all_tables=0x7f68fc32a1f8) at /home/travis/src/sql/sql_parse.cc:6477
 
#15 0x0000564a43a53454 in mysql_execute_command (thd=0x7f68fc009c00) at /home/travis/src/sql/sql_parse.cc:3484
 
#16 0x0000564a43a61276 in mysql_parse (thd=0x7f68fc009c00, rawbuf=0x7f68fc01a158 "SELECT DISTINCT CASE WHEN table_schema = 'information_schema' THEN 'INFORMATION_SCHEMA' ELSE table_schema END AS table_schema, table_name, CASE WHEN table_type = 'BASE TABLE' THEN 'table' WHEN table_t"..., length=1291, parser_state=0x7f69466f4210, is_com_multi=false, is_next_command=false) at /home/travis/src/sql/sql_parse.cc:8009
 
#17 0x0000564a43a4ed0d in dispatch_command (command=COM_QUERY, thd=0x7f68fc009c00, packet=0x7f68fc022381 "SELECT DISTINCT CASE WHEN table_schema = 'information_schema' THEN 'INFORMATION_SCHEMA' ELSE table_schema END AS table_schema, table_name, CASE WHEN table_type = 'BASE TABLE' THEN 'table' WHEN table_t"..., packet_length=1291, is_com_multi=false, is_next_command=false) at /home/travis/src/sql/sql_parse.cc:1824
 
#18 0x0000564a43a4d670 in do_command (thd=0x7f68fc009c00) at /home/travis/src/sql/sql_parse.cc:1378
 
#19 0x0000564a43b9feae in do_handle_one_connection (connect=0x564a45bae570) at /home/travis/src/sql/sql_connect.cc:1335
 
#20 0x0000564a43b9fc3b in handle_one_connection (arg=0x564a45bae570) at /home/travis/src/sql/sql_connect.cc:1241
 
#21 0x00007f694dccd184 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
 
#22 0x00007f694d1d9ffd in clone () from /lib/x86_64-linux-gnu/libc.so.6

To reproduce, you can use the same data.tar.gz that's already attached.

  • start the server on it (all default options will do);
  • run mysql_upgrade
  • run 

    CHECK TABLE test.t9 EXTENDED;
    		 
    SELECT * FROM INFORMATION_SCHEMA.COLUMNS;

Comment by Marko Mäkelä [ 2018-09-26 ]

The branch 10.2-MDEV-17199 contains an initial patch for InnoDB as well as a fix of MDEV-14046.

These cannot be meaningfully tested before the bugs in the .frm file parsing have been fixed. It is possible that my InnoDB fix for MDEV-17199 is incomplete; we would only know once the failures outside InnoDB code have been fixed.

Comment by Elena Stepanova [ 2018-10-21 ]

I've raised the priority because, in addition to the blocked testing, we now have an external report of a similar nature, MDEV-17498. It's not 100% certain that it's the same issue, but we can't rule it out without trying a fix.

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