[MDEV-14022] Upgrade from 10.0/10.1 fails on assertion `!is_user_rec || !leaf || index->is_dummy || dict_index_is_ibuf(index) || n == n_fields || (n >= index->n_core_fields && n <= index->n_fields)' Created: 2017-10-06  Updated: 2017-10-13  Resolved: 2017-10-09

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.3
Fix Version/s: 10.3.2

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

Attachments: File data-10.0.tar.gz    
Issue Links:
Problem/Incident
is caused by MDEV-11369 Instant add column for InnoDB Closed
Relates
relates to MDEV-14062 Upgrade from 10.0 fails on assertion ... Closed

 Description   

No workflow is needed. To reproduce, it's enough to bootstrap 10.0 or 10.1 server with default options, and then start 10.3 on the data directory.

The pre-bootstrapped 10.0 datadir is attached.

10.3 debug 2d2f857fb371a

 
mysqld: /data/src/10.3/storage/innobase/rem/rem0rec.cc:845: ulint* rec_get_offsets_func(const rec_t*, const dict_index_t*, ulint*, bool, ulint, const char*, unsigned int, mem_heap_t**): Assertion `!is_user_rec || !leaf || index->is_dummy || dict_index_is_ibuf(index) || n == n_fields || (n >= index->n_core_fields && n <= index->n_fields)' failed.
 
171006 15:36:48 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007f091c7cfee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
 
#8  0x000056522c37061b in rec_get_offsets_func (rec=0x7f08f8010154 "", index=0x565230012308, offsets=0x7ffd370aa260, leaf=true, n_fields=1, file=0x56522c9a3d60 "/data/src/10.3/storage/innobase/page/page0cur.cc", line=678, heap=0x7ffd370aa1f0) at /data/src/10.3/storage/innobase/rem/rem0rec.cc:842
 
#9  0x000056522c336088 in page_cur_search_with_match_bytes (block=0x7f08f79a0cc0, index=0x565230012308, tuple=0x565230015358, mode=PAGE_CUR_GE, iup_matched_fields=0x7ffd370aa650, iup_matched_bytes=0x7ffd370aa658, ilow_matched_fields=0x7ffd370aa660, ilow_matched_bytes=0x7ffd370aa668, cursor=0x7ffd370ab7c8) at /data/src/10.3/storage/innobase/page/page0cur.cc:678
 
#10 0x000056522c4cdfd0 in btr_cur_search_to_nth_level (index=0x565230012308, level=0, tuple=0x565230015358, mode=PAGE_CUR_GE, latch_mode=1, cursor=0x7ffd370ab7c0, has_search_latch=0, file=0x56522ca72ca8 "/data/src/10.3/storage/innobase/dict/dict0load.cc", line=2437, mtr=0x7ffd370ac520, autoinc=0) at /data/src/10.3/storage/innobase/btr/btr0cur.cc:1697
 
#11 0x000056522c4e3a15 in btr_pcur_open_low (index=0x565230012308, level=0, tuple=0x565230015358, mode=PAGE_CUR_GE, latch_mode=1, cursor=0x7ffd370ab7c0, file=0x56522ca72ca8 "/data/src/10.3/storage/innobase/dict/dict0load.cc", line=2437, autoinc=0, mtr=0x7ffd370ac520) at /data/src/10.3/storage/innobase/include/btr0pcur.ic:459
 
#12 0x000056522c4e54bd in btr_pcur_open_on_user_rec_func (index=0x565230012308, tuple=0x565230015358, mode=PAGE_CUR_GE, latch_mode=1, cursor=0x7ffd370ab7c0, file=0x56522ca72ca8 "/data/src/10.3/storage/innobase/dict/dict0load.cc", line=2437, mtr=0x7ffd370ac520) at /data/src/10.3/storage/innobase/btr/btr0pcur.cc:599
 
#13 0x000056522c57352e in dict_load_indexes (table=0x56522ff6a528, heap=0x5652300152d0, ignore_err=DICT_ERR_IGNORE_NONE) at /data/src/10.3/storage/innobase/dict/dict0load.cc:2437
 
#14 0x000056522c575f92 in dict_load_sys_table (table=0x56522ff6a528) at /data/src/10.3/storage/innobase/dict/dict0load.cc:3249
 
#15 0x000056522c542dc1 in dict_boot () at /data/src/10.3/storage/innobase/dict/dict0boot.cc:528
 
#16 0x000056522c43ca81 in innobase_start_or_create_for_mysql () at /data/src/10.3/storage/innobase/srv/srv0start.cc:2196
 
#17 0x000056522c2561d8 in innobase_init (p=0x56522f2020f0) at /data/src/10.3/storage/innobase/handler/ha_innodb.cc:4151
 
#18 0x000056522bf343e4 in ha_initialize_handlerton (plugin=0x56522f1f4048) at /data/src/10.3/sql/handler.cc:521
 
#19 0x000056522bc8b82d in plugin_initialize (tmp_root=0x7ffd370b42a0, plugin=0x56522f1f4048, argc=0x56522d3323b0 <remaining_argc>, argv=0x56522f19d7e8, options_only=false) at /data/src/10.3/sql/sql_plugin.cc:1440
 
#20 0x000056522bc8c4a7 in plugin_init (argc=0x56522d3323b0 <remaining_argc>, argv=0x56522f19d7e8, flags=2) at /data/src/10.3/sql/sql_plugin.cc:1723
 
#21 0x000056522bb862fe in init_server_components () at /data/src/10.3/sql/mysqld.cc:5339
 
#22 0x000056522bb873b3 in mysqld_main (argc=11, argv=0x56522f19d7e8) at /data/src/10.3/sql/mysqld.cc:5932
 
#23 0x000056522bb7bf50 in main (argc=11, argv=0x7ffd370b4ab8) at /data/src/10.3/sql/main.cc:25

Non-debug build seems to be working all right.

Removing the assertion does not help much, it fails with another one:

mysqld: /data/src/10.3-bug/storage/innobase/rem/rem0rec.cc:518: bool rec_offs_validate(const rec_t*, const dict_index_t*, const ulint*): Assertion `!is_user_rec || n >= i || !index || n >= index->n_core_fields' failed.
 
171006 15:44:22 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007f8b91d56ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
 
#8  0x000055f6820d1791 in rec_offs_validate (rec=0x7f8b7001008c "", index=0x55f6858ed318, offsets=0x7ffcf3a2d1d0) at /data/src/10.3-bug/storage/innobase/rem/rem0rec.cc:517
 
#9  0x000055f682051b49 in lock_clust_rec_read_check_and_lock (flags=0, block=0x7f8b6f9a0cc0, rec=0x7f8b7001008c "", index=0x55f6858ed318, offsets=0x7ffcf3a2d1d0, mode=LOCK_X, gap_mode=0, thr=0x55f68550a468) at /data/src/10.3-bug/storage/innobase/lock/lock0lock.cc:7198
 
#10 0x000055f682154b56 in sel_set_rec_lock (pcur=0x55f685508830, rec=0x7f8b7001008c "", index=0x55f6858ed318, offsets=0x7ffcf3a2d1d0, mode=3, type=0, thr=0x55f68550a468, mtr=0x7ffcf3a2d4f0) at /data/src/10.3-bug/storage/innobase/row/row0sel.cc:1247
 
#11 0x000055f682155de5 in row_sel (node=0x55f6855081e8, thr=0x55f68550a468) at /data/src/10.3-bug/storage/innobase/row/row0sel.cc:1867
 
#12 0x000055f68215707e in row_sel_step (thr=0x55f68550a468) at /data/src/10.3-bug/storage/innobase/row/row0sel.cc:2398
 
#13 0x000055f6820c59ab in que_thr_step (thr=0x55f68550a468) at /data/src/10.3-bug/storage/innobase/que/que0que.cc:1031
 
#14 0x000055f6820c5d37 in que_run_threads_low (thr=0x55f68550a468) at /data/src/10.3-bug/storage/innobase/que/que0que.cc:1116
 
#15 0x000055f6820c5f19 in que_run_threads (thr=0x55f68550a468) at /data/src/10.3-bug/storage/innobase/que/que0que.cc:1156
 
#16 0x000055f6820c61ba in que_eval_sql (info=0x0, sql=0x55f682736280 <row_merge_drop_temp_indexes()::sql> "PROCEDURE DROP_TEMP_INDEXES_PROC () IS\nixid CHAR;\nfound INT;\nDECLARE CURSOR index_cur IS\n SELECT ID FROM SYS_INDEXES\n WHERE SUBSTR(NAME,0,1)='\377'\nFOR UPDATE;\nBEGIN\nfound := 1;\nOPEN index_cur;\nWHILE fou"..., reserve_dict_mutex=0, trx=0x7f8b900bf878) at /data/src/10.3-bug/storage/innobase/que/que0que.cc:1233
 
#17 0x000055f6821108f9 in row_merge_drop_temp_indexes () at /data/src/10.3-bug/storage/innobase/row/row0merge.cc:4030
 
#18 0x000055f682072511 in recv_recovery_rollback_active () at /data/src/10.3-bug/storage/innobase/log/log0recv.cc:3490
 
#19 0x000055f68219f5bf in innobase_start_or_create_for_mysql () at /data/src/10.3-bug/storage/innobase/srv/srv0start.cc:2472
 
#20 0x000055f681fb81d8 in innobase_init (p=0x55f684add0f0) at /data/src/10.3-bug/storage/innobase/handler/ha_innodb.cc:4151
 
#21 0x000055f681c963e4 in ha_initialize_handlerton (plugin=0x55f684acf048) at /data/src/10.3-bug/sql/handler.cc:521
 
#22 0x000055f6819ed82d in plugin_initialize (tmp_root=0x7ffcf3a34d30, plugin=0x55f684acf048, argc=0x55f6830973b0 <remaining_argc>, argv=0x55f684a787e8, options_only=false) at /data/src/10.3-bug/sql/sql_plugin.cc:1440
 
#23 0x000055f6819ee4a7 in plugin_init (argc=0x55f6830973b0 <remaining_argc>, argv=0x55f684a787e8, flags=2) at /data/src/10.3-bug/sql/sql_plugin.cc:1723
 
#24 0x000055f6818e82fe in init_server_components () at /data/src/10.3-bug/sql/mysqld.cc:5339
 
#25 0x000055f6818e93b3 in mysqld_main (argc=11, argv=0x55f684a787e8) at /data/src/10.3-bug/sql/mysqld.cc:5932
 
#26 0x000055f6818ddf50 in main (argc=11, argv=0x7ffcf3a35548) at /data/src/10.3-bug/sql/main.cc:25



 Comments   
Comment by Marko Mäkelä [ 2017-10-06 ]

I believe that the reason for this is that before 10.2, the SYS_INDEXES table did not contain the column MERGE_THRESHOLD. Tables that are created in 10.2 will always have the SYS_INDEXEX.MERGE_THRESOLD column stored, but older tables lack it.

These debug assertions must be relaxed so that for SYS_INDEXES, both numbers of columns will be accepted. My bad for not testing this in the scope of MDEV-11369. I did write some relaxed debug assertions on this, but I missed these ones.

Comment by Marko Mäkelä [ 2017-10-09 ]

Fixed by relaxing the two failing assertions

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