[MDEV-23258] InnoDB: Failing assertion: 0 in row_sel_convert_mysql_key_to_innobase Created: 2020-07-22  Updated: 2023-04-27  Resolved: 2023-04-25

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Update, Storage Engine - InnoDB
Affects Version/s: 10.1
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: not-10.2, not-10.3, not-10.4, not-10.5

Issue Links:
Relates
relates to MDEV-21245 Assertion `0' failed in row_sel_conve... Closed
relates to MDEV-21798 Assertion `0' failed in row_sel_conve... Closed

 Description   

Setting to Minor because it's a debug assertion which only seems to affect 10.1

--source include/have_innodb.inc
 
CREATE TABLE t1 (a INT, b CHAR(8), c INT, UNIQUE(c,a), KEY (b)) ENGINE=InnoDB;
INSERT INTO t1 VALUES (1,'foo',NULL), (2,'bar',2);
REPLACE INTO t1 SELECT * FROM t1;
--error ER_DUP_ENTRY
UPDATE t1 SET c = 0 WHERE b > 'baz';
 
# Cleanup
DROP TABLE t1;

10.1 57ec42bc

2020-07-22 15:02:02 7f5157ff6700  InnoDB: Warning: using a partial-field key prefix in search.
InnoDB: index `b` of table `test`.`t1`. Last data field length 9 bytes,
InnoDB: key ptr now exceeds key end by 3 bytes.
InnoDB: Key value in the MySQL format:
 len 6; hex 000000000202; asc       ;
2020-07-22 15:02:02 7f5157ff6700  InnoDB: Assertion failure in thread 139987345434368 in file row0sel.cc line 2500
InnoDB: Failing assertion: 0
 
#5  0x00007f51563df42a in __GI_abort () at abort.c:89
#6  0x00007f514f828e8f in row_sel_convert_mysql_key_to_innobase (tuple=0x7f513fd353f8, buf=0x7f513fd353e8 "\200", buf_len=8, index=0x7f513fde8578, key_ptr=0x7f513fc9d251 "\245\245\245\245\245\245\245", '\217' <repeats 193 times>..., key_len=6, trx=0x7f513fc64478) at /data/src/10.1/storage/innobase/row/row0sel.cc:2500
#7  0x00007f514f6f4b82 in ha_innodb::index_read (this=0x7f513fcac888, buf=0x7f513fc9cfa0 "\371\001", key_ptr=0x7f513fc9d248 "", key_len=6, find_flag=HA_READ_KEY_EXACT) at /data/src/10.1/storage/innobase/handler/ha_innodb.cc:9372
#8  0x00007f514f6f5fc5 in ha_innodb::rnd_pos (this=0x7f513fcac888, buf=0x7f513fc9cfa0 "\371\001", pos=0x7f513fc9d248 "") at /data/src/10.1/storage/innobase/handler/ha_innodb.cc:9960
#9  0x000055c90391522f in handler::ha_rnd_pos (this=0x7f513fcac888, buf=0x7f513fc9cfa0 "\371\001", pos=0x7f513fc9d248 "") at /data/src/10.1/sql/handler.cc:2671
#10 0x000055c9037af9d1 in prepare_record_for_error_message (error=121, table=0x7f513fc7dc70) at /data/src/10.1/sql/sql_update.cc:215
#11 0x000055c9037b1908 in mysql_update (thd=0x7f514cb61070, table_list=0x7f513fcf6180, fields=..., values=..., conds=0x7f513fcf6ae8, order_num=0, order=0x0, limit=18446744073709551614, handle_duplicates=DUP_ERROR, ignore=false, found_return=0x7f5157ff4cf0, updated_return=0x7f5157ff4d80) at /data/src/10.1/sql/sql_update.cc:856
#12 0x000055c9036d262a in mysql_execute_command (thd=0x7f514cb61070) at /data/src/10.1/sql/sql_parse.cc:3506
#13 0x000055c9036ddde0 in mysql_parse (thd=0x7f514cb61070, rawbuf=0x7f513fcf6088 "UPDATE t1 SET c = 0 WHERE b > 'baz'", length=35, parser_state=0x7f5157ff55f0) at /data/src/10.1/sql/sql_parse.cc:7200
#14 0x000055c9036ccfb7 in dispatch_command (command=COM_QUERY, thd=0x7f514cb61070, packet=0x7f514ca9b071 "UPDATE t1 SET c = 0 WHERE b > 'baz'", packet_length=35) at /data/src/10.1/sql/sql_parse.cc:1491
#15 0x000055c9036cbe9c in do_command (thd=0x7f514cb61070) at /data/src/10.1/sql/sql_parse.cc:1123
#16 0x000055c903809d3b in do_handle_one_connection (thd_arg=0x7f514cb61070) at /data/src/10.1/sql/sql_connect.cc:1331
#17 0x000055c903809a6c in handle_one_connection (arg=0x7f514cb61070) at /data/src/10.1/sql/sql_connect.cc:1242
#18 0x000055c903c27ed4 in pfs_spawn_thread (arg=0x7f5150fae3f0) at /data/src/10.1/storage/perfschema/pfs.cc:1868
#19 0x00007f5157c854a4 in start_thread (arg=0x7f5157ff6700) at pthread_create.c:456
#20 0x00007f5156493d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Couldn't reproduce on 10.2+, although there are similar open bugs affecting these versions.



 Comments   
Comment by Marko Mäkelä [ 2020-07-22 ]

The InnoDB warning using a partial-field key prefix in search is indicating serious misuse of the handler API. One case of that was fixed in MDEV-11167, but that was supposed to be in 10.1 as well. Maybe this bug is repeatable in newer versions with suitable configuration parameters?

Comment by Elena Stepanova [ 2020-07-22 ]

Maybe it represents as MDEV-21245 or MDEV-21798 in newer versions.
Otherwise sure, maybe configuration parameters could affect this variation as well, I just can't guess what those parameters would be. If you have any suggestions, I can certainly try.

Generated at Thu Feb 08 09:21:03 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.