[MDEV-18904] Assertion `m_part_spec.start_part >= m_part_spec.end_part' failed in ha_partition::index_read_idx_map Created: 2019-03-12  Updated: 2019-03-23  Resolved: 2019-03-23

Status: Closed
Project: MariaDB Server
Component/s: Partitioning
Affects Version/s: 10.4
Fix Version/s: 10.4.4

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Sachin Setiya (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Problem/Incident
is caused by MDEV-371 Unique indexes for blobs Closed

 Description   

--source include/have_partition.inc
 
CREATE TABLE t1 (a INT, UNIQUE USING HASH (a)) PARTITION BY HASH (a) PARTITIONS 2;
INSERT INTO t1 VALUES (2);
REPLACE INTO t1 VALUES (2);
 
# Cleanup
DROP TABLE t1;

10.4 5a796f1f

mysqld: /data/src/10.4/sql/ha_partition.cc:5767: virtual int ha_partition::index_read_idx_map(uchar*, uint, const uchar*, key_part_map, ha_rkey_function): Assertion `m_part_spec.start_part >= m_part_spec.end_part' failed.
190312 15:04:57 [ERROR] mysqld got signal 6 ;
 
#7  0x00007ffb498fcee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x000056199ee7aa5a in ha_partition::index_read_idx_map (this=0x7ffb28139fb8, buf=0x7ffb280428f8 '\245' <repeats 16 times>, " )\004(\373\177", index=0, key=0x7ffb44276220 "", keypart_map=1, find_flag=HA_READ_KEY_EXACT) at /data/src/10.4/sql/ha_partition.cc:5767
#9  0x000056199e6f93e2 in handler::ha_index_read_idx_map (this=0x7ffb28139fb8, buf=0x7ffb280428f8 '\245' <repeats 16 times>, " )\004(\373\177", index=0, key=0x7ffb44276220 "", keypart_map=1, find_flag=HA_READ_KEY_EXACT) at /data/src/10.4/sql/handler.cc:3068
#10 0x000056199e365b32 in write_record (thd=0x7ffb28000b00, table=0x7ffb28139150, info=0x7ffb44276460) at /data/src/10.4/sql/sql_insert.cc:1772
#11 0x000056199e363bdd in mysql_insert (thd=0x7ffb28000b00, table_list=0x7ffb280155b0, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_REPLACE, ignore=false) at /data/src/10.4/sql/sql_insert.cc:1067
#12 0x000056199e3afe08 in mysql_execute_command (thd=0x7ffb28000b00) at /data/src/10.4/sql/sql_parse.cc:4838
#13 0x000056199e3bbb63 in mysql_parse (thd=0x7ffb28000b00, rawbuf=0x7ffb280154c8 "REPLACE INTO t1 VALUES (2)", length=26, parser_state=0x7ffb44277180, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8204
#14 0x000056199e3a71a5 in dispatch_command (command=COM_QUERY, thd=0x7ffb28000b00, packet=0x7ffb2800a781 "REPLACE INTO t1 VALUES (2)", packet_length=26, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1829
#15 0x000056199e3a598b in do_command (thd=0x7ffb28000b00) at /data/src/10.4/sql/sql_parse.cc:1358
#16 0x000056199e51f703 in do_handle_one_connection (connect=0x5619a2675570) at /data/src/10.4/sql/sql_connect.cc:1399
#17 0x000056199e51f474 in handle_one_connection (arg=0x5619a2675570) at /data/src/10.4/sql/sql_connect.cc:1302
#18 0x000056199ea15031 in pfs_spawn_thread (arg=0x5619a2767be0) at /data/src/10.4/storage/perfschema/pfs.cc:1862
#19 0x00007ffb4b5d3494 in start_thread (arg=0x7ffb44278700) at pthread_create.c:333
#20 0x00007ffb499b993f in clone () from /lib/x86_64-linux-gnu/libc.so.6

It started happening after MDEV-371, although there is no direct relation in the test case.
Reproducible with at least MyISAM and InnoDB.
Also reproducible on bb-10.4-sachin 42af178a.



 Comments   
Comment by Sachin Setiya (Inactive) [ 2019-03-18 ]

bb-10.4-sachin

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