[MDEV-18086] Assertion `len <= col->len || ((col->mtype) == 5 || (col->mtype) == 14) || (col->len == 0 && col->mtype == 1)' failed in rec_get_converted_size_comp_prefix_low upon UPDATE after upgrade from 10.1 Created: 2018-12-26  Updated: 2019-03-19  Resolved: 2019-03-19

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Virtual Columns
Affects Version/s: 10.2
Fix Version/s: 10.2.23, 10.3.14, 10.4.4

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

Attachments: File data.tar.gz    
Issue Links:
Relates
relates to MDEV-18087 Server crashes in mach_read_from_n_li... Closed
relates to MDEV-18090 Assertion `dict_table_get_n_cols(old_... Closed
relates to MDEV-18165 ulint rec_get_converted_size_comp_pre... Closed
relates to MDEV-18084 Server crashes in row_upd_changes_som... Closed
relates to MDEV-18085 Assertion `!col->mbmaxlen || len >= c... Closed

 Description   

See also MDEV-18084, MDEV-18085.

10.2 debug 734029fa796

mysqld: /data/src/10.2/storage/innobase/rem/rem0rec.cc:875: ulint rec_get_converted_size_comp_prefix_low(const dict_index_t*, const dfield_t*, ulint, ulint*, bool): Assertion `len <= col->len || ((col->mtype) == 5 ||
 (col->mtype) == 14) || (col->len == 0 && col->mtype == 1)' failed.
181226 22:45:20 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f03aa399ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x00005644e64f7e6f in rec_get_converted_size_comp_prefix_low (index=0x7f0340028918, fields=0x7f03400283d0, n_fields=4, extra=0x0, temp=false) at /data/src/10.2/storage/innobase/rem/rem0rec.cc:874
#9  0x00005644e64f8346 in rec_get_converted_size_comp (index=0x7f0340028918, status=0, fields=0x7f03400283d0, n_fields=4, extra=0x0) at /data/src/10.2/storage/innobase/rem/rem0rec.cc:990
#10 0x00005644e663045d in rec_get_converted_size (index=0x7f0340028918, dtuple=0x7f0340028388, n_ext=0) at /data/src/10.2/storage/innobase/include/rem0rec.ic:1654
#11 0x00005644e663d140 in btr_cur_optimistic_update (flags=2, cursor=0x7f03400281c0, offsets=0x7f03a8098160, heap=0x7f03a8098200, update=0x7f0340025f68, cmpl_info=1, thr=0x7f0340026158, trx_id=3334, mtr=0x7f03a8098570) at /data/src/10.2/storage/innobase/btr/btr0cur.cc:4052
#12 0x00005644e65966a6 in row_upd_clust_rec (flags=0, node=0x7f0340025e50, index=0x7f0340028918, offsets=0x7f03a8098250, offsets_heap=0x7f03a8098200, thr=0x7f0340026158, mtr=0x7f03a8098570) at /data/src/10.2/storage/innobase/row/row0upd.cc:2858
#13 0x00005644e65974e5 in row_upd_clust_step (node=0x7f0340025e50, thr=0x7f0340026158) at /data/src/10.2/storage/innobase/row/row0upd.cc:3182
#14 0x00005644e65978d2 in row_upd (node=0x7f0340025e50, thr=0x7f0340026158) at /data/src/10.2/storage/innobase/row/row0upd.cc:3279
#15 0x00005644e6597dab in row_upd_step (thr=0x7f0340026158) at /data/src/10.2/storage/innobase/row/row0upd.cc:3425
#16 0x00005644e653e437 in row_update_for_mysql (prebuilt=0x7f0340025678) at /data/src/10.2/storage/innobase/row/row0mysql.cc:1830
#17 0x00005644e6404786 in ha_innobase::update_row (this=0x7f034001e6b8, old_row=0x7f034000c378 "\377\001", new_row=0x7f034000c360 "\377\002") at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:9000
#18 0x00005644e60f8a17 in handler::ha_update_row (this=0x7f034001e6b8, old_data=0x7f034000c378 "\377\001", new_data=0x7f034000c360 "\377\002") at /data/src/10.2/sql/handler.cc:5993
#19 0x00005644e5f5f458 in mysql_update (thd=0x7f0340000b00, table_list=0x7f03400111b8, fields=..., values=..., conds=0x7f0340011d00, order_num=0, order=0x0, limit=18446744073709551615, handle_duplicates=DUP_ERROR, ignore=false, found_return=0x7f03a80998b0, updated_return=0x7f03a8099960) at /data/src/10.2/sql/sql_update.cc:809
#20 0x00005644e5e72cab in mysql_execute_command (thd=0x7f0340000b00) at /data/src/10.2/sql/sql_parse.cc:4292
#21 0x00005644e5e7e7f7 in mysql_parse (thd=0x7f0340000b00, rawbuf=0x7f03400110c0 "UPDATE t1 SET pk = pk + 1 WHERE pk = 1", length=38, parser_state=0x7f03a809a250, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:8014
#22 0x00005644e5e6c12f in dispatch_command (command=COM_QUERY, thd=0x7f0340000b00, packet=0x7f03400191a1 "UPDATE t1 SET pk = pk + 1 WHERE pk = 1", packet_length=38, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1825
#23 0x00005644e5e6aa92 in do_command (thd=0x7f0340000b00) at /data/src/10.2/sql/sql_parse.cc:1379
#24 0x00005644e5fbd569 in do_handle_one_connection (connect=0x5644e8ec9460) at /data/src/10.2/sql/sql_connect.cc:1335
#25 0x00005644e5fbd2f6 in handle_one_connection (arg=0x5644e8ec9460) at /data/src/10.2/sql/sql_connect.cc:1241
#26 0x00007f03abe55494 in start_thread (arg=0x7f03a809b700) at pthread_create.c:333
#27 0x00007f03aa45693f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Non-debug builds don't seem to be affected.
On 10.3 and 10.4 the assertion failure is the same as in MDEV-18084.

To reproduce:

  • start 10.1 server with all defaults (current 10.1 9ad1663f78 or 10.1.37 will do, I didn't check other versions);
  • run

    CREATE TABLE t1 (v TIMESTAMP(2) AS (t) VIRTUAL, pk SERIAL, t TIMESTAMP(6) NULL, PRIMARY KEY(pk));
    INSERT INTO t1 () VALUES ();
    

  • shutdown server normally;
  • start 10.2+ server with all defaults on the same datadir;
  • run mysql_upgrade (optionally, it doesn't affect the outcome);
  • run

    UPDATE t1 SET pk = pk + 1 WHERE pk = 1
    

The datadir pre-created on current 10.1 as described is attached.



 Comments   
Comment by Elena Stepanova [ 2019-01-08 ]

Linked with MDEV-18165 for possible relationship – same assertion, but different versions and circumstances.

Comment by Elena Stepanova [ 2019-03-19 ]

Fixed by the patch for MDEV-18084

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