[MDEV-18371] Server crashes in ha_innobase::cmp_ref upon UPDATE with PARTITION clause Created: 2019-01-24  Updated: 2021-04-19  Resolved: 2020-07-17

Status: Closed
Project: MariaDB Server
Component/s: Partitioning, Storage Engine - InnoDB
Affects Version/s: 10.3, 10.4, 10.5
Fix Version/s: 10.3.24, 10.4.14, 10.5.5

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Alexey Botchkov
Resolution: Fixed Votes: 0
Labels: affects-tests


 Description   

See also MDEV-18244, it probably has the same root cause. The problem described here appeared in 10.3 with the same commit that is pointed at in MDEV-18244.

--source include/have_innodb.inc
 
--source include/have_partition.inc
 
 
 
CREATE TABLE t1 (a INT, b INT, KEY (a)) ENGINE=InnoDB PARTITION BY KEY(b) PARTITIONS 4;
 
INSERT INTO t1 VALUES (3,0),(8,2),(7,8),(3,4),(2,4),(0,7),(4,3),(3,6);
 
FLUSH TABLES;
 
UPDATE t1 PARTITION (p3,p1) SET a = 2 WHERE a = 3;
 
 
 
# Cleanup
 
DROP TABLE t1;

10.3 55be043c13d

 
#3  <signal handler called>
 
#4  0x0000556b7d49d7c3 in ha_innobase::cmp_ref (this=0x7f0aa4120ff8, ref1=0x7f0aa412f04c "", ref2=0x7f0aa412f03b "") at /data/src/10.3/storage/innobase/handler/ha_innodb.cc:16651
 
#5  0x0000556b7d8ce01e in cmp_key_rowid_part_id (ptr=0x7f0aa4120798, ref1=0x7f0aa412f041 "\003", ref2=0x7f0aa412f030 "\001") at /data/src/10.3/sql/ha_partition.cc:5553
 
#6  0x0000556b7d9102db in _downheap (queue=0x7f0aa4120cc8, start_idx=1, element=0x7f0aa412f030 "\001") at /data/src/10.3/mysys/queues.c:305
 
#7  0x0000556b7d91047a in queue_fix (queue=0x7f0aa4120cc8) at /data/src/10.3/mysys/queues.c:354
 
#8  0x0000556b7d8d4212 in ha_partition::handle_ordered_index_scan (this=0x7f0aa4120798, buf=0x7f0aa413d938 "\371\003", reverse_order=false) at /data/src/10.3/sql/ha_partition.cc:7643
 
#9  0x0000556b7d8d09ea in ha_partition::multi_range_read_next (this=0x7f0aa4120798, range_info=0x7f0ae7dfcee0) at /data/src/10.3/sql/ha_partition.cc:6480
 
#10 0x0000556b7d2dceaa in QUICK_RANGE_SELECT::get_next (this=0x7f0aa415fbe0) at /data/src/10.3/sql/opt_range.cc:11469
 
#11 0x0000556b7d2ee89a in rr_quick (info=0x7f0ae7dfd170) at /data/src/10.3/sql/records.cc:365
 
#12 0x0000556b7cdd675b in READ_RECORD::read_record (this=0x7f0ae7dfd170) at /data/src/10.3/sql/records.h:73
 
#13 0x0000556b7cf69feb in mysql_update (thd=0x7f0aa4000b00, table_list=0x7f0aa4014e70, fields=..., values=..., conds=0x7f0aa4015850, order_num=0, order=0x0, limit=18446744073709551615, handle_duplicates=DUP_ERROR, ignore=false, found_return=0x7f0ae7dfd6f0, updated_return=0x7f0ae7dfd7b0) at /data/src/10.3/sql/sql_update.cc:739
 
#14 0x0000556b7ce72221 in mysql_execute_command (thd=0x7f0aa4000b00) at /data/src/10.3/sql/sql_parse.cc:4581
 
#15 0x0000556b7ce7d63d in mysql_parse (thd=0x7f0aa4000b00, rawbuf=0x7f0aa4014cd8 "UPDATE t1 PARTITION (p3,p1) SET a = 2 WHERE a = 3", length=49, parser_state=0x7f0ae7dfe5f0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:8092
 
#16 0x0000556b7ce6a7f1 in dispatch_command (command=COM_QUERY, thd=0x7f0aa4000b00, packet=0x7f0aa400b1e1 "UPDATE t1 PARTITION (p3,p1) SET a = 2 WHERE a = 3", packet_length=49, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1851
 
#17 0x0000556b7ce69215 in do_command (thd=0x7f0aa4000b00) at /data/src/10.3/sql/sql_parse.cc:1396
 
#18 0x0000556b7cfd122a in do_handle_one_connection (connect=0x556b8097b9e0) at /data/src/10.3/sql/sql_connect.cc:1402
 
#19 0x0000556b7cfd0fae in handle_one_connection (arg=0x556b8097b9e0) at /data/src/10.3/sql/sql_connect.cc:1308
 
#20 0x0000556b7d46b89f in pfs_spawn_thread (arg=0x556b80992780) at /data/src/10.3/storage/perfschema/pfs.cc:1862
 
#21 0x00007f0af47c3494 in start_thread (arg=0x7f0ae7dff700) at pthread_create.c:333
 
#22 0x00007f0af2ba993f in clone () from /lib/x86_64-linux-gnu/libc.so.6

All of debug, ASAN and non-debug builds fail the same way.

There is initial analysis by marko in a comment to MDEV-18244.

 Comments   
Comment by Hartmut Holzgraefe [ 2019-10-18 ]

Still reproducible on all recent 10.3.x versions up to 10.3.18, but on 10.4 the original UPDATE test only fails up to 10.4.2, but not on later versions ...

Comment by Hartmut Holzgraefe [ 2019-11-01 ]

With MDEV-18244 now being fixed, does this also fix this bug report?

Comment by Alice Sherepa [ 2020-03-11 ]

Similar test case:

--source include/have_partition.inc
 
--source include/have_innodb.inc
 
 
 
CREATE TABLE t1 ( a int, b int, KEY (b)) ENGINE=InnoDB
 
PARTITION BY LIST (a)
 
(PARTITION p0 VALUES IN (NULL,8), PARTITION p1 VALUES IN (2,9,1), PARTITION p2 VALUES IN (0,4,3), PARTITION pdef DEFAULT);
 
 
 
INSERT INTO t1 VALUES (8,4),(8,4),(8,4),(8,4),(8,9),(8,9),(8,3),(8,3),(8,8),(8,9),(8,8),(8,9),(1,5),(1,5),(9,4),(9,4),(1,5),(1,5),(1,4),(1,4),(2,4),(2,4),(9,7),(9,7),(1,6),(1,7),(1,6),(1,7),(1,7),(1,6),(1,7),(1,6),(9,0),(9,0),(1,0),(1,0),(1,0),(1,0),(1,0),(1,7),(1,0),(1,7),(2,6),(2,6),(2,6),(2,1),(9,6),(2,6),(2,1),(9,6),(2,7),(2,7),(9,9),(9,9),(1,9),(1,9),(9,3),(9,3),(1,9),(1,9),(1,3),(1,3),(1,2),(1,2),(1,9),(9,8),(1,9),(9,8),(2,9),(1,3),(2,9),(1,3),(1,2),(1,2),(1,9),(1,9),(1,9),(2,2),(1,9),(2,2),(2,3),(2,3),(9,2),(9,2),(2,8),(2,8),(0,4),(3,4),(0,4),(3,4),(4,5),(4,5),(4,4),(4,4),(3,0),(3,0),(4,6),(3,6),(4,6),(3,6),(4,6),(4,6),(0,1),(0,1),(4,6),(3,1),(4,6),(3,1),(0,1),(0,1),(0,0),(0,0),(3,0),(3,7),(3,0),(0,7),(3,7),(0,7),(3,1),(0,1),(3,1),(0,1),(4,6),(4,6),(3,6),(3,6),(4,3),(0,8),(4,3),(0,8),(3,2),(4,3),(3,2),(4,3),(0,8),(3,9),(0,8),(3,9),(3,2),(3,2),(0,2),(0,2),(0,8),(0,8),(4,3),(3,9),(4,3),(3,9),(3,3),(3,3),(3,9),(0,9),(3,9),(0,9),(3,9),(0,2),(3,9),(0,2),(4,3),(4,3),(3,3),(3,3),(3,1),(3,4),(3,4),(3,1),(3,1),(3,0),(3,0),(3,1),(3,1),(3,0),(3,0),(3,6),(3,6),(3,1),(3,1),(3,7),(3,7),(3,2),(3,2),(3,2),(3,2),(3,8),(3,8),(3,8),(3,8),(3,1),(7,5),(7,5),(6,6),(6,6),(7,7),(7,7),(6,0),(6,0),(7,6),(7,6),(7,1),(7,1),(7,6),(7,6),(7,1),(7,1),(6,7),(6,7),(7,3),(7,3),(6,9),(6,9),(6,9),(6,9),(7,3),(7,3),(7,3),(6,2),(7,3),(6,2);
 
 
 
flush tables;
 
SELECT COUNT(*) FROM t1 PARTITION (p1,p2) ;

10.3 8fa1b6bb88be39001b9

 
#3  <signal handler called>
 
#4  ha_innobase::cmp_ref (this=0x7f1ff01479f8, ref1=0x7f1ff009d96c "", ref2=0x7f1ff009d95b "") at /10.3/storage/innobase/handler/ha_innodb.cc:16958
 
#5  0x000055b4748ee18d in cmp_key_rowid_part_id (ptr=0x7f1ff01380a8, ref1=0x7f1ff009d961 "\002", ref2=0x7f1ff009d950 "\001") at /10.3/sql/ha_partition.cc:5581
 
#6  0x000055b474986759 in _downheap (queue=0x7f1ff01385e8, start_idx=1, element=0x7f1ff009d950 "\001") at /10.3/mysys/queues.c:305
 
#7  0x000055b4749868fa in queue_fix (queue=0x7f1ff01385e8) at /10.3/mysys/queues.c:354
 
#8  0x000055b4748f47bc in ha_partition::handle_ordered_index_scan (this=0x7f1ff01380a8, buf=0x7f1ff0025eb8 "\377", reverse_order=false) at /10.3/sql/ha_partition.cc:7676
 
#9  0x000055b4748ee701 in ha_partition::common_first_last (this=0x7f1ff01380a8, buf=0x7f1ff0025eb8 "\377") at /10.3/sql/ha_partition.cc:5763
 
#10 0x000055b4748ee55e in ha_partition::index_first (this=0x7f1ff01380a8, buf=0x7f1ff0025eb8 "\377") at /10.3/sql/ha_partition.cc:5707
 
#11 0x000055b4740e0ecd in handler::ha_index_first (this=0x7f1ff01380a8, buf=0x7f1ff0025eb8 "\377") at /10.3/sql/handler.cc:2989
 
#12 0x000055b473e40513 in join_read_first (tab=0x7f1ff00146d8) at /10.3/sql/sql_select.cc:20666
 
#13 0x000055b473e3dc61 in sub_select (join=0x7f1ff0013550, join_tab=0x7f1ff00146d8, end_of_records=false) at /10.3/sql/sql_select.cc:19665
 
#14 0x000055b473e3d14d in do_select (join=0x7f1ff0013550, procedure=0x0) at /10.3/sql/sql_select.cc:19208
 
#15 0x000055b473e14512 in JOIN::exec_inner (this=0x7f1ff0013550) at /10.3/sql/sql_select.cc:4098
 
#16 0x000055b473e138e2 in JOIN::exec (this=0x7f1ff0013550) at /10.3/sql/sql_select.cc:3892
 
#17 0x000055b473e14bef in mysql_select (thd=0x7f1ff0000d50, tables=0x7f1ff0012df8, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f1ff0013528, unit=0x7f1ff0004c18, select_lex=0x7f1ff00053a0) at /10.3/sql/sql_select.cc:4297
 
#18 0x000055b473e06430 in handle_select (thd=0x7f1ff0000d50, lex=0x7f1ff0004b58, result=0x7f1ff0013528, setup_tables_done_option=0) at /10.3/sql/sql_select.cc:370
 
#19 0x000055b473dce134 in execute_sqlcom_select (thd=0x7f1ff0000d50, all_tables=0x7f1ff0012df8) at /10.3/sql/sql_parse.cc:6293
 
#20 0x000055b473dc4ba9 in mysql_execute_command (thd=0x7f1ff0000d50) at /10.3/sql/sql_parse.cc:3820
 
#21 0x000055b473dd2410 in mysql_parse (thd=0x7f1ff0000d50, rawbuf=0x7f1ff0012a78 "SELECT COUNT(*) FROM t1 PARTITION (p1,p2)", length=41, parser_state=0x7f203d02a5c0, is_com_multi=false, is_next_command=false) at /10.3/sql/sql_parse.cc:7817
 
#22 0x000055b473dbf095 in dispatch_command (command=COM_QUERY, thd=0x7f1ff0000d50, packet=0x7f1ff0008ed1 "", packet_length=42, is_com_multi=false, is_next_command=false) at /10.3/sql/sql_parse.cc:1855
 
#23 0x000055b473dbd9e8 in do_command (thd=0x7f1ff0000d50) at /10.3/sql/sql_parse.cc:1401
 
#24 0x000055b473f33981 in do_handle_one_connection (connect=0x55b477fd9620) at /10.3/sql/sql_connect.cc:1403
 
#25 0x000055b473f336e3 in handle_one_connection (arg=0x55b477fd9620) at /10.3/sql/sql_connect.cc:1308
 
#26 0x000055b4748c6c49 in pfs_spawn_thread (arg=0x55b477f75530) at /10.3/storage/perfschema/pfs.cc:1869
 
#27 0x00007f2044597fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
 
#28 0x00007f2043f434cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
 
 

Comment by Roel Van de Paar [ 2020-04-08 ]

ha_innobase::cmp_ref also SIGSEGV's on DELETE without partitioning, ref MDEV-22187, perhaps fix at same time?

Comment by Alexey Botchkov [ 2020-07-17 ]

https://github.com/MariaDB/server/commit/2cae58f8918f64c77227cfa07ab2fd24c3580f81

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