[MDEV-23949] Assertion `0' failed in JOIN_CACHE::get_match_flag_by_pos Created: 2020-10-12  Updated: 2023-09-25

Status: Open
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.4, 10.5
Fix Version/s: 10.4, 10.5

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Igor Babaev
Resolution: Unresolved Votes: 0
Labels: None


 Description    

--source include/have_innodb.inc
 
 
 
CREATE TABLE t1 (a CHAR(8)) ENGINE=InnoDB;
 
INSERT INTO t1 VALUES ('foo');
 
 
 
CREATE TABLE t2 (b VARCHAR(574)) ENGINE=InnoDB;
 
INSERT INTO t2 VALUES ('bar'),('baz');
 
 
 
CREATE TABLE t3 (e INT, d TEXT, PRIMARY KEY(e,d(8))) ENGINE=InnoDB;
 
INSERT INTO t3 VALUES (1,'qux');
 
 
 
CREATE TABLE t4 (f INT, KEY(f)) ENGINE=InnoDB;
 
INSERT INTO t4 VALUES (1),(2);
 
 
 
SET SESSION join_cache_level= 4;
 
SET SESSION join_buffer_space_limit= 16384;
 
 
 
SELECT DISTINCT a FROM t1 WHERE a IN (SELECT t2.b FROM t2 INNER JOIN t3 INNER JOIN t4 ON (t4.f = t3.e));

10.4 c2ac0ce1

 
mysqld: /data/src/10.4/sql/sql_join_cache.cc:1682: virtual JOIN_CACHE::Match_flag JOIN_CACHE::get_match_flag_by_pos(uchar*): Assertion `0' failed.
 
201013  1:30:36 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007fb81a9fdf36 in __GI___assert_fail (assertion=0x559a41d96730 "0", file=0x559a41d967b0 "/data/src/10.4/sql/sql_join_cache.cc", line=1682, function=0x559a41d969e0 "virtual JOIN_CACHE::Match_flag JOIN_CACHE::get_match_flag_by_pos(uchar*)") at assert.c:101
 
#8  0x0000559a4115a767 in JOIN_CACHE::get_match_flag_by_pos (this=0x7fb7c407aaf8, rec_ptr=0x7fb7c4070d44 "\375\375\003") at /data/src/10.4/sql/sql_join_cache.cc:1682
 
#9  0x0000559a4115b0d8 in JOIN_CACHE::skip_if_not_needed_match (this=0x7fb7c407aaf8) at /data/src/10.4/sql/sql_join_cache.cc:2006
 
#10 0x0000559a4115d85c in JOIN_CACHE_BNL::skip_next_candidate_for_match (this=0x7fb7c407aaf8, rec_ptr=0x7fb7c4070d44 "\375\375\003") at /data/src/10.4/sql/sql_join_cache.cc:3568
 
#11 0x0000559a4115b8ff in JOIN_CACHE::join_matching_records (this=0x7fb7c407aaf8, skip_last=false) at /data/src/10.4/sql/sql_join_cache.cc:2292
 
#12 0x0000559a4115b262 in JOIN_CACHE::join_records (this=0x7fb7c407aaf8, skip_last=false) at /data/src/10.4/sql/sql_join_cache.cc:2088
 
#13 0x0000559a410045e9 in sub_select_cache (join=0x7fb7c4018520, join_tab=0x7fb7c4079690, end_of_records=true) at /data/src/10.4/sql/sql_select.cc:20186
 
#14 0x0000559a410047fc in sub_select (join=0x7fb7c4018520, join_tab=0x7fb7c40792e8, end_of_records=true) at /data/src/10.4/sql/sql_select.cc:20357
 
#15 0x0000559a410047fc in sub_select (join=0x7fb7c4018520, join_tab=0x7fb7c4078f40, end_of_records=true) at /data/src/10.4/sql/sql_select.cc:20357
 
#16 0x0000559a410047fc in sub_select (join=0x7fb7c4018520, join_tab=0x7fb7c4078b98, end_of_records=true) at /data/src/10.4/sql/sql_select.cc:20357
 
#17 0x0000559a41003f62 in do_select (join=0x7fb7c4018520, procedure=0x0) at /data/src/10.4/sql/sql_select.cc:19948
 
#18 0x0000559a40fd8c07 in JOIN::exec_inner (this=0x7fb7c4018520) at /data/src/10.4/sql/sql_select.cc:4478
 
#19 0x0000559a40fd7d36 in JOIN::exec (this=0x7fb7c4018520) at /data/src/10.4/sql/sql_select.cc:4260
 
#20 0x0000559a40fd948a in mysql_select (thd=0x7fb7c4000d90, tables=0x7fb7c4013b40, wild_num=0, fields=..., conds=0x7fb7c4017990, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748609, result=0x7fb7c40184f8, unit=0x7fb7c4004cc0, select_lex=0x7fb7c4013578) at /data/src/10.4/sql/sql_select.cc:4695
 
#21 0x0000559a40fc8e9b in handle_select (thd=0x7fb7c4000d90, lex=0x7fb7c4004c00, result=0x7fb7c40184f8, setup_tables_done_option=0) at /data/src/10.4/sql/sql_select.cc:410
 
#22 0x0000559a40f8e738 in execute_sqlcom_select (thd=0x7fb7c4000d90, all_tables=0x7fb7c4013b40) at /data/src/10.4/sql/sql_parse.cc:6355
 
#23 0x0000559a40f84d88 in mysql_execute_command (thd=0x7fb7c4000d90) at /data/src/10.4/sql/sql_parse.cc:3889
 
#24 0x0000559a40f92743 in mysql_parse (thd=0x7fb7c4000d90, rawbuf=0x7fb7c4013448 "SELECT DISTINCT a FROM t1 WHERE a IN (SELECT t2.b FROM t2 INNER JOIN t3 INNER JOIN t4 ON (t4.f = t3.e))", length=103, parser_state=0x7fb8143c3550, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7896
 
#25 0x0000559a40f7ec4e in dispatch_command (command=COM_QUERY, thd=0x7fb7c4000d90, packet=0x7fb7c40087a1 "", packet_length=103, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1834
 
#26 0x0000559a40f7d4b6 in do_command (thd=0x7fb7c4000d90) at /data/src/10.4/sql/sql_parse.cc:1352
 
#27 0x0000559a4110b2cb in do_handle_one_connection (connect=0x559a441ff350) at /data/src/10.4/sql/sql_connect.cc:1412
 
#28 0x0000559a4110b014 in handle_one_connection (arg=0x559a441ff350) at /data/src/10.4/sql/sql_connect.cc:1316
 
#29 0x0000559a41b23b4a in pfs_spawn_thread (arg=0x559a44108250) at /data/src/10.4/storage/perfschema/pfs.cc:1869
 
#30 0x00007fb81af15609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 
#31 0x00007fb81aae9293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Reproducible on 10.4 and 10.5.
The test case above does not fail on 10.3, but the plan is different there, so maybe with some adjustments to the query and/or data the failure can be reproduced on earlier versions as well.
No obvious failure on a non-debug build.

Plan on 10.4 (fails)

 
EXPLAIN EXTENDED SELECT DISTINCT a FROM t1 WHERE a IN (SELECT t2.b FROM t2 INNER JOIN t3 INNER JOIN t4 ON (t4.f = t3.e));
 
id	select_type	table	type	possible_keys	key	key_len	ref	rows	filtered	Extra
 
1	PRIMARY	t1	ALL	NULL	NULL	NULL	NULL	1	100.00	Using temporary
 
1	PRIMARY	t3	index	PRIMARY	PRIMARY	14	NULL	1	100.00	Using index
 
1	PRIMARY	t4	hash_index	f	#hash#f:f	5:5	test.t3.e	2	50.00	Using index
 
1	PRIMARY	t2	ALL	NULL	NULL	NULL	NULL	2	100.00	Using where; FirstMatch(t1); Using join buffer (flat, BNL join)
 
Warnings:
 
Note	1003	select distinct `test`.`t1`.`a` AS `a` from `test`.`t1` semi join (`test`.`t2` join `test`.`t3` join `test`.`t4`) where `test`.`t4`.`f` = `test`.`t3`.`e` and `test`.`t1`.`a` = `test`.`t2`.`b`

Plan on 10.3 (does not fail)

 
EXPLAIN EXTENDED SELECT DISTINCT a FROM t1 WHERE a IN (SELECT t2.b FROM t2 INNER JOIN t3 INNER JOIN t4 ON (t4.f = t3.e));
 
id	select_type	table	type	possible_keys	key	key_len	ref	rows	filtered	Extra
 
1	PRIMARY	t1	ALL	NULL	NULL	NULL	NULL	1	100.00	Using temporary
 
1	PRIMARY	t3	index	PRIMARY	PRIMARY	14	NULL	1	100.00	Using index
 
1	PRIMARY	t4	hash_index	f	#hash#f:f	5:5	test.t3.e	2	50.00	Using index
 
1	PRIMARY	t2	ALL	NULL	NULL	NULL	NULL	2	100.00	Using where; FirstMatch(t1)
 
Warnings:
 
Note	1003	select distinct `test`.`t1`.`a` AS `a` from `test`.`t1` semi join (`test`.`t2` join `test`.`t3` join `test`.`t4`) where `test`.`t4`.`f` = `test`.`t3`.`e` and `test`.`t1`.`a` = `test`.`t2`.`b`



 Comments   
Comment by Ramesh Sivaraman [ 2023-09-22 ]

Another test case where only11.3 debug build crashes. psergei Since the crash is only on 11.3 debug build should we treat it as a separate ticket?

CREATE TABLE t (a INT);
 
SET JOIN_buffer_space_limit=1;
 
CREATE TABLE t2 (a INT(1),b TEXT,KEY(a));
 
INSERT INTO t VALUES (1);
 
INSERT INTO t2 (a,b) VALUES (1,1);
 
SELECT 1 FROM t2 WHERE b in (SELECT 1 FROM t A,t B WHERE B.a<5);

Leads to:

11.3.0 8ad1e26b1bafa4ed9928306efc10c047f2274108 (Debug)

 
mariadbd: /test/11.3_dbg/sql/sql_join_cache.cc:1692: virtual JOIN_CACHE::Match_flag JOIN_CACHE::get_match_flag_by_pos(uchar*): Assertion `0' failed.

11.3.0 8ad1e26b1bafa4ed9928306efc10c047f2274108 (Debug)

 
Core was generated by `/test/MD080923-mariadb-11.3.0-linux-x86_64-dbg/bin/mariadbd --no-defaults --cor'.
 
Program terminated with signal SIGABRT, Aborted.
 
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
 
[Current thread is 1 (Thread 0x1468000e2700 (LWP 2495920))]
 
(gdb) bt
 
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
 
#1  0x000014682c471859 in __GI_abort () at abort.c:79
 
#2  0x000014682c471729 in __assert_fail_base (fmt=0x14682c607588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x5609bac91329 "0", file=0x5609bab25398 "/test/11.3_dbg/sql/sql_join_cache.cc", line=1692, function=<optimized out>) at assert.c:92
 
#3  0x000014682c482fd6 in __GI___assert_fail (assertion=assertion@entry=0x5609bac91329 "0", file=file@entry=0x5609bab25398 "/test/11.3_dbg/sql/sql_join_cache.cc", line=line@entry=1692, function=function@entry=0x5609bab253c0 "virtual JOIN_CACHE::Match_flag JOIN_CACHE::get_match_flag_by_pos(uchar*)") at assert.c:101
 
#4  0x00005609ba09f08d in JOIN_CACHE::get_match_flag_by_pos (this=<optimized out>, rec_ptr=<optimized out>) at /test/11.3_dbg/sql/sql_join_cache.cc:1692
 
#5  0x00005609ba09f2da in JOIN_CACHE::skip_if_not_needed_match (this=0x1467c407d068) at /test/11.3_dbg/sql/sql_join_cache.cc:2069
 
#6  0x00005609ba09ed67 in JOIN_CACHE_BNL::skip_next_candidate_for_match (this=<optimized out>, rec_ptr=<optimized out>) at /test/11.3_dbg/sql/sql_join_cache.cc:3676
 
#7  0x00005609ba0a2e7f in JOIN_CACHE::join_matching_records (this=0x1467c407d068, skip_last=false) at /test/11.3_dbg/sql/sql_join_cache.cc:2372
 
#8  0x00005609ba0a255d in JOIN_CACHE::join_records (this=this@entry=0x1467c407d068, skip_last=skip_last@entry=false) at /test/11.3_dbg/sql/sql_join_cache.cc:2158
 
#9  0x00005609b9f4e39c in sub_select_cache (join=0x1467c4075ef0, join_tab=0x1467c4078a68, end_of_records=<optimized out>) at /test/11.3_dbg/sql/sql_select.cc:23186
 
#10 0x00005609b9f4dd8f in sub_select (join=0x1467c4075ef0, join_tab=0x1467c40785f0, end_of_records=true) at /test/11.3_dbg/sql/sql_select.cc:23371
 
#11 0x00005609b9f4dd8f in sub_select (join=0x1467c4075ef0, join_tab=0x1467c4078178, end_of_records=true) at /test/11.3_dbg/sql/sql_select.cc:23371
 
#12 0x00005609b9f87907 in do_select (procedure=<optimized out>, join=0x1467c4075ef0) at /test/11.3_dbg/sql/sql_select.cc:22957
 
#13 JOIN::exec_inner (this=this@entry=0x1467c4075ef0) at /test/11.3_dbg/sql/sql_select.cc:4935
 
#14 0x00005609b9f87e34 in JOIN::exec (this=this@entry=0x1467c4075ef0) at /test/11.3_dbg/sql/sql_select.cc:4712
 
#15 0x00005609b9f85cb2 in mysql_select (thd=thd@entry=0x1467c4000d48, tables=0x1467c40138f0, fields=@0x1467c4013620: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x1467c40138a8, last = 0x1467c40138a8, elements = 1}, <No data fields>}, conds=0x1467c4016198, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2164525824, result=0x1467c4016d30, unit=0x1467c4005060, select_lex=0x1467c4013368) at /test/11.3_dbg/sql/sql_select.cc:5243
 
#16 0x00005609b9f86450 in handle_select (thd=thd@entry=0x1467c4000d48, lex=lex@entry=0x1467c4004f80, result=result@entry=0x1467c4016d30, setup_tables_done_option=setup_tables_done_option@entry=0) at /test/11.3_dbg/sql/sql_select.cc:628
 
#17 0x00005609b9eea81b in execute_sqlcom_select (thd=thd@entry=0x1467c4000d48, all_tables=0x1467c40138f0) at /test/11.3_dbg/sql/sql_parse.cc:6023
 
#18 0x00005609b9ef6b07 in mysql_execute_command (thd=thd@entry=0x1467c4000d48, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/11.3_dbg/sql/sql_parse.cc:3922
 
#19 0x00005609b9ee4bfb in mysql_parse (thd=thd@entry=0x1467c4000d48, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x1468000e12c0) at /test/11.3_dbg/sql/sql_parse.cc:7760
 
#20 0x00005609b9ef22cc in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x1467c4000d48, packet=packet@entry=0x1467c400af59 "", packet_length=packet_length@entry=63, blocking=blocking@entry=true) at /test/11.3_dbg/sql/sql_class.h:1489
 
#21 0x00005609b9ef4784 in do_command (thd=0x1467c4000d48, blocking=blocking@entry=true) at /test/11.3_dbg/sql/sql_parse.cc:1406
 
#22 0x00005609ba05d375 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x5609bda39c78, put_in_cache=put_in_cache@entry=true) at /test/11.3_dbg/sql/sql_connect.cc:1445
 
#23 0x00005609ba05d844 in handle_one_connection (arg=0x5609bda39c78) at /test/11.3_dbg/sql/sql_connect.cc:1347
 
#24 0x000014682c982609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 
#25 0x000014682c56e133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug confirmed present in:
MariaDB: 11.3.0 (dbg)

Bug (or feature/syntax) confirmed not present in:
MariaDB: 10.4.32 (dbg), 10.4.32 (opt), 10.5.23 (dbg), 10.5.23 (opt), 10.6.16 (dbg), 10.6.16 (opt), 10.9.8 (dbg), 10.9.8 (opt), 10.10.7 (dbg), 10.10.7 (opt), 10.11.6 (dbg), 10.11.6 (opt), 11.0.4 (dbg), 11.0.4 (opt), 11.1.3 (dbg), 11.1.3 (opt), 11.2.2 (dbg), 11.2.2 (opt), 11.3.0 (opt)

Comment by Sergei Petrunia [ 2023-09-25 ]

Reassigning to Igor as previous experience shows others do mis-fixes in this area of the code.

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