[MDEV-27366] SIGSEGV in handler_index_cond_check on SELECT in connection with rowid_filter setting Created: 2021-12-26  Updated: 2023-09-28

Status: In Review
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.5, 10.6, 10.7, 10.8, 10.9, 10.10
Fix Version/s: 10.5, 10.6

Type: Bug Priority: Critical
Reporter: Roel Van de Paar Assignee: Sergei Petrunia
Resolution: Unresolved Votes: 0
Labels: not-10.2, not-10.3, not-10.4, regression-10.5

Issue Links:
Relates
relates to MDEV-27292 Assertion `!prebuilt->index->is_prima... Open
relates to MDEV-28747 Possible problem with ha_innobase::bu... Closed
relates to MDEV-22846 Server crashes in handler_index_cond_... Closed
relates to MDEV-28712 join_cache.test shows plans that mean... Open

 Description    

SET sql_mode='';
 
SET join_cache_level=3;
 
CREATE TABLE t (c BIGINT, d INT, KEY c(c), KEY d(d)) ENGINE=InnoDB;
 
INSERT INTO t VALUES (0,0),(1,2),(1,3),(2,0),(3,0),(4,6),(5,0);
 
SELECT * FROM t,t AS b WHERE t.c=0 AND t.d=b.c AND t.c=b.d;

Leads to:

10.8.0 ccdf5711a8fff0cd610a91fdcf37c8ff1182878c (Optimized)

 
Core was generated by `/test/MD121221-mariadb-10.8.0-linux-x86_64-opt/bin/mysqld --no-defaults --core-'.
 
Program terminated with signal SIGSEGV, Segmentation fault.
 
#0  0x000055cb1b08680f in handler_index_cond_check (h_arg=0x14831c049e60)
 
    at /test/10.8_opt/sql/handler.cc:6708
 
6708	  if ((res= h->pushed_idx_cond->val_int()? CHECK_POS : CHECK_NEG) ==
 
[Current thread is 1 (Thread 0x148392175700 (LWP 635439))]
 
(gdb) bt
 
#0  0x000055cb1b08680f in handler_index_cond_check (h_arg=0x14831c049e60) at /test/10.8_opt/sql/handler.cc:6708
 
#1  0x000055cb1b441635 in row_search_idx_cond_check (mysql_rec=0x14831c049a48 <incomplete sequence \371>, prebuilt=0x14831c04aab0, rec=0x1483947c407e <error: Cannot access memory at address 0x1483947c407e>, offsets=0x148392172850) at /test/10.8_opt/storage/innobase/row/row0sel.cc:4045
 
#2  0x000055cb1b444c8a in row_search_mvcc (buf=buf@entry=0x14831c049a48 <incomplete sequence \371>, mode=<optimized out>, mode@entry=PAGE_CUR_G, prebuilt=0x14831c04aab0, match_mode=match_mode@entry=0, direction=direction@entry=0) at /test/10.8_opt/storage/innobase/row/row0sel.cc:5414
 
#3  0x000055cb1b375960 in ha_innobase::index_read (find_flag=HA_READ_AFTER_KEY, key_len=0, key_ptr=0x0, buf=0x14831c049a48 <incomplete sequence \371>, this=0x14831c049e60) at /test/10.8_opt/storage/innobase/handler/ha_innodb.cc:9002
 
#4  ha_innobase::index_first (buf=0x14831c049a48 <incomplete sequence \371>, this=0x14831c049e60) at /test/10.8_opt/storage/innobase/handler/ha_innodb.cc:9364
 
#5  ha_innobase::rnd_next (buf=0x14831c049a48 <incomplete sequence \371>, this=0x14831c049e60) at /test/10.8_opt/storage/innobase/handler/ha_innodb.cc:9457
 
#6  ha_innobase::rnd_next (this=0x14831c049e60, buf=0x14831c049a48 <incomplete sequence \371>) at /test/10.8_opt/storage/innobase/handler/ha_innodb.cc:9447
 
#7  0x000055cb1b07fd57 in handler::ha_rnd_next (this=0x14831c049e60, buf=0x14831c049a48 <incomplete sequence \371>) at /test/10.8_opt/sql/handler.cc:3393
 
#8  0x000055cb1ad690c4 in rr_sequential (info=0x14831c04d728) at /test/10.8_opt/sql/records.h:82
 
#9  0x000055cb1af8578f in JOIN_CACHE::join_matching_records (this=0x14831c04ee60, skip_last=false) at /test/10.8_opt/sql/sql_join_cache.cc:2329
 
#10 0x000055cb1af85141 in JOIN_CACHE::join_records (this=this@entry=0x14831c04ee60, skip_last=skip_last@entry=false) at /test/10.8_opt/sql/sql_join_cache.cc:2151
 
#11 0x000055cb1ae81b9a in sub_select_cache (join=0x14831c013478, join_tab=0x14831c04d660, end_of_records=<optimized out>) at /test/10.8_opt/sql/sql_select.cc:20844
 
#12 0x000055cb1aeaf2df in do_select (procedure=<optimized out>, join=0x14831c013478) at /test/10.8_opt/sql/sql_select.cc:20619
 
#13 JOIN::exec_inner (this=0x14831c013478) at /test/10.8_opt/sql/sql_select.cc:4735
 
#14 0x000055cb1aeaf848 in JOIN::exec (this=this@entry=0x14831c013478) at /test/10.8_opt/sql/sql_select.cc:4513
 
#15 0x000055cb1aead941 in mysql_select (thd=0x14831c000c58, tables=0x14831c010f60, fields=@0x14831c010c28: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x14831c010f18, last = 0x14831c013f30, elements = 4}, <No data fields>}, conds=0x14831c0125e0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=<optimized out>, result=0x14831c013450, unit=0x14831c004ea0, select_lex=0x14831c010988) at /test/10.8_opt/sql/sql_select.cc:4993
 
#16 0x000055cb1aeae0f7 in handle_select (thd=thd@entry=0x14831c000c58, lex=lex@entry=0x14831c004dc8, result=result@entry=0x14831c013450, setup_tables_done_option=setup_tables_done_option@entry=0) at /test/10.8_opt/sql/sql_select.cc:545
 
#17 0x000055cb1ae2ec01 in execute_sqlcom_select (thd=0x14831c000c58, all_tables=0x14831c010f60) at /test/10.8_opt/sql/sql_parse.cc:6253
 
#18 0x000055cb1ae3cef2 in mysql_execute_command (thd=0x14831c000c58, is_called_from_prepared_stmt=<optimized out>) at /test/10.8_opt/sql/sql_parse.cc:3944
 
#19 0x000055cb1ae29986 in mysql_parse (thd=0x14831c000c58, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at /test/10.8_opt/sql/sql_parse.cc:8028
 
#20 0x000055cb1ae35b35 in dispatch_command (command=COM_QUERY, thd=0x14831c000c58, packet=<optimized out>, packet_length=<optimized out>, blocking=<optimized out>) at /test/10.8_opt/sql/sql_class.h:1360
 
#21 0x000055cb1ae37d27 in do_command (thd=0x14831c000c58, blocking=blocking@entry=true) at /test/10.8_opt/sql/sql_parse.cc:1402
 
#22 0x000055cb1af562e7 in do_handle_one_connection (connect=<optimized out>, put_in_cache=true) at /test/10.8_opt/sql/sql_connect.cc:1418
 
#23 0x000055cb1af5662d in handle_one_connection (arg=arg@entry=0x55cb1dbe5be8) at /test/10.8_opt/sql/sql_connect.cc:1312
 
#24 0x000055cb1b2c45d8 in pfs_spawn_thread (arg=0x55cb1db9d218) at /test/10.8_opt/storage/perfschema/pfs.cc:2201
 
#25 0x00001483b1316609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 
#26 0x00001483b0f04293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

10.8.0 ccdf5711a8fff0cd610a91fdcf37c8ff1182878c (Debug)

 
Core was generated by `/test/MD121221-mariadb-10.8.0-linux-x86_64-dbg/bin/mysqld --no-defaults --core-'.
 
Program terminated with signal SIGSEGV, Segmentation fault.
 
#0  0x000055f9f0af1c63 in handler_index_cond_check (h_arg=0x1463a00728e0)
 
    at /test/10.8_dbg/sql/handler.cc:6708
 
6708	  if ((res= h->pushed_idx_cond->val_int()? CHECK_POS : CHECK_NEG) ==
 
[Current thread is 1 (Thread 0x1464505a2700 (LWP 636278))]
 
(gdb) bt
 
#0  0x000055f9f0af1c63 in handler_index_cond_check (h_arg=0x1463a00728e0) at /test/10.8_dbg/sql/handler.cc:6708
 
#1  0x000055f9f10622ac in row_search_idx_cond_check (mysql_rec=mysql_rec@entry=0x1463a0072458 <incomplete sequence \371>, prebuilt=prebuilt@entry=0x1463a00735c8, rec=rec@entry=0x14643cc5c07e "", offsets=0x14645059f520) at /test/10.8_dbg/storage/innobase/row/row0sel.cc:4045
 
#2  0x000055f9f106d0a9 in row_search_mvcc (buf=buf@entry=0x1463a0072458 <incomplete sequence \371>, mode=PAGE_CUR_G, prebuilt=0x1463a00735c8, match_mode=<optimized out>, direction=direction@entry=0) at /test/10.8_dbg/storage/innobase/row/row0sel.cc:5414
 
#3  0x000055f9f0ea45c5 in ha_innobase::index_read (this=this@entry=0x1463a00728e0, buf=buf@entry=0x1463a0072458 <incomplete sequence \371>, key_ptr=key_ptr@entry=0x0, key_len=key_len@entry=0, find_flag=find_flag@entry=HA_READ_AFTER_KEY) at /test/10.8_dbg/storage/innobase/handler/ha_innodb.cc:9002
 
#4  0x000055f9f0ea484c in ha_innobase::index_first (this=this@entry=0x1463a00728e0, buf=buf@entry=0x1463a0072458 <incomplete sequence \371>) at /test/10.8_dbg/storage/innobase/handler/ha_innodb.cc:9364
 
#5  0x000055f9f0ea48d5 in ha_innobase::rnd_next (this=0x1463a00728e0, buf=0x1463a0072458 <incomplete sequence \371>) at /test/10.8_dbg/storage/innobase/handler/ha_innodb.cc:9457
 
#6  0x000055f9f0ae8561 in handler::ha_rnd_next (this=0x1463a00728e0, buf=0x1463a0072458 <incomplete sequence \371>) at /test/10.8_dbg/sql/handler.cc:3393
 
#7  0x000055f9f06d6445 in rr_sequential (info=0x1463a00763e8) at /test/10.8_dbg/sql/records.h:82
 
#8  0x000055f9f0859b30 in READ_RECORD::read_record (this=0x1463a00763e8) at /test/10.8_dbg/sql/records.h:81
 
#9  join_init_read_record (tab=0x1463a0076320) at /test/10.8_dbg/sql/sql_select.cc:22065
 
#10 0x000055f9f09a1827 in JOIN_TAB_SCAN::open (this=0x1463a0077f58) at /test/10.8_dbg/sql/sql_join_cache.cc:3426
 
#11 0x000055f9f09a4c2d in JOIN_CACHE::join_matching_records (this=0x1463a0077da0, skip_last=false) at /test/10.8_dbg/sql/sql_join_cache.cc:2329
 
#12 0x000055f9f09a4482 in JOIN_CACHE::join_records (this=this@entry=0x1463a0077da0, skip_last=skip_last@entry=false) at /test/10.8_dbg/sql/sql_join_cache.cc:2151
 
#13 0x000055f9f0841336 in sub_select_cache (join=0x1463a0016998, join_tab=0x1463a0076320, end_of_records=<optimized out>) at /test/10.8_dbg/sql/sql_select.cc:20844
 
#14 0x000055f9f0840dfb in sub_select (join=0x1463a0016998, join_tab=0x1463a0075f70, end_of_records=<optimized out>) at /test/10.8_dbg/sql/sql_select.cc:21014
 
#15 0x000055f9f0878fcc in do_select (procedure=<optimized out>, join=0x1463a0016998) at /test/10.8_dbg/sql/sql_select.cc:20619
 
#16 JOIN::exec_inner (this=this@entry=0x1463a0016998) at /test/10.8_dbg/sql/sql_select.cc:4735
 
#17 0x000055f9f0879542 in JOIN::exec (this=this@entry=0x1463a0016998) at /test/10.8_dbg/sql/sql_select.cc:4513
 
#18 0x000055f9f0877553 in mysql_select (thd=thd@entry=0x1463a0000db8, tables=0x1463a0014480, fields=@0x1463a0014148: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x1463a0014438, last = 0x1463a0017450, elements = 4}, <No data fields>}, conds=0x1463a0015b00, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x1463a0016970, unit=0x1463a00051c0, select_lex=0x1463a0013ea8) at /test/10.8_dbg/sql/sql_select.cc:4993
 
#19 0x000055f9f0877808 in handle_select (thd=thd@entry=0x1463a0000db8, lex=lex@entry=0x1463a00050e8, result=result@entry=0x1463a0016970, setup_tables_done_option=setup_tables_done_option@entry=0) at /test/10.8_dbg/sql/sql_select.cc:545
 
#20 0x000055f9f07d6c1e in execute_sqlcom_select (thd=thd@entry=0x1463a0000db8, all_tables=0x1463a0014480) at /test/10.8_dbg/sql/sql_parse.cc:6253
 
#21 0x000055f9f07e3af1 in mysql_execute_command (thd=thd@entry=0x1463a0000db8, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/10.8_dbg/sql/sql_parse.cc:3944
 
#22 0x000055f9f07cfe0f in mysql_parse (thd=thd@entry=0x1463a0000db8, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x1464505a1400) at /test/10.8_dbg/sql/sql_parse.cc:8028
 
#23 0x000055f9f07deaab in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x1463a0000db8, packet=packet@entry=0x1463a000b879 "", packet_length=packet_length@entry=58, blocking=blocking@entry=true) at /test/10.8_dbg/sql/sql_class.h:1360
 
#24 0x000055f9f07e1eea in do_command (thd=0x1463a0000db8, blocking=blocking@entry=true) at /test/10.8_dbg/sql/sql_parse.cc:1402
 
#25 0x000055f9f095b89c in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55f9f466be38, put_in_cache=put_in_cache@entry=true) at /test/10.8_dbg/sql/sql_connect.cc:1418
 
#26 0x000055f9f095bea1 in handle_one_connection (arg=arg@entry=0x55f9f466be38) at /test/10.8_dbg/sql/sql_connect.cc:1312
 
#27 0x000055f9f0ddd442 in pfs_spawn_thread (arg=0x55f9f457f4a8) at /test/10.8_dbg/storage/perfschema/pfs.cc:2201
 
#28 0x0000146459d15609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 
#29 0x0000146459903293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug confirmed present in:
MariaDB: 10.5.14 (dbg), 10.5.14 (opt), 10.6.6 (dbg), 10.6.6 (opt), 10.7.2 (dbg), 10.7.2 (opt), 10.8.0 (dbg), 10.8.0 (opt)

Bug (or feature/syntax) confirmed not present in:
MariaDB: 10.2.42 (dbg), 10.2.42 (opt), 10.3.33 (dbg), 10.3.33 (opt), 10.4.23 (dbg), 10.4.23 (opt)
MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.51 (dbg), 5.6.51 (opt), 5.7.36 (dbg), 5.7.36 (opt), 8.0.27 (dbg), 8.0.27 (opt)

Setting rowid_filter=off prevents the crash from occurring.

Some older ASAN Traces:

10.6.0 3f871b339429441ad907ecf7dfabdc414797e664 (Debug)

 
2021-04-27 10:18:23 0 [Note] /test/UBASAN_MD260121-mariadb-10.6.0-linux-x86_64-dbg/bin/mysqld: ready for connections.
 
Version: '10.6.0-MariaDB-debug'  socket: '/test/UBASAN_MD260121-mariadb-10.6.0-linux-x86_64-dbg/socket.sock'  port: 32200  MariaDB Server
 
/data/builds/10.6_dbg_san/sql/handler.cc:6343:40: runtime error: member call on null pointer of type 'struct Item'
 
    #0 0x55e4bd3e4d6e in handler_index_cond_check /data/builds/10.6_dbg_san/sql/handler.cc:6343
 
    #1 0x55e4bf8a7542 in row_search_idx_cond_check /data/builds/10.6_dbg_san/storage/innobase/row/row0sel.cc:3989
 
    #2 0x55e4bf8d1c3c in row_search_mvcc(unsigned char*, page_cur_mode_t, row_prebuilt_t*, unsigned long, unsigned long) /data/builds/10.6_dbg_san/storage/innobase/row/row0sel.cc:5336
 
    #3 0x55e4bf1c310a in ha_innobase::index_read(unsigned char*, unsigned char const*, unsigned int, ha_rkey_function) /data/builds/10.6_dbg_san/storage/innobase/handler/ha_innodb.cc:8546
 
    #4 0x55e4bf1c4a73 in ha_innobase::index_first(unsigned char*) /data/builds/10.6_dbg_san/storage/innobase/handler/ha_innodb.cc:8907
 
    #5 0x55e4bf1c4d6b in ha_innobase::rnd_next(unsigned char*) /data/builds/10.6_dbg_san/storage/innobase/handler/ha_innodb.cc:9000
 
    #6 0x55e4bd39cea8 in handler::ha_rnd_next(unsigned char*) /data/builds/10.6_dbg_san/sql/handler.cc:3066
 
    #7 0x55e4be47f57d in rr_sequential(READ_RECORD*) /data/builds/10.6_dbg_san/sql/records.cc:519
 
    #8 0x55e4bc07d90d in READ_RECORD::read_record() /data/builds/10.6_dbg_san/sql/records.h:81
 
    #9 0x55e4bc07d90d in join_init_read_record(st_join_table*) /data/builds/10.6_dbg_san/sql/sql_select.cc:21577
 
    #10 0x55e4bc96e0c4 in JOIN_TAB_SCAN::open() /data/builds/10.6_dbg_san/sql/sql_join_cache.cc:3358
 
    #11 0x55e4bc994a42 in JOIN_CACHE::join_matching_records(bool) /data/builds/10.6_dbg_san/sql/sql_join_cache.cc:2261
 
    #12 0x55e4bc98fac4 in JOIN_CACHE::join_records(bool) /data/builds/10.6_dbg_san/sql/sql_join_cache.cc:2093
 
    #13 0x55e4bbfc2ade in sub_select_cache(JOIN*, st_join_table*, bool) /data/builds/10.6_dbg_san/sql/sql_select.cc:20376
 
    #14 0x55e4bbfc02dc in sub_select(JOIN*, st_join_table*, bool) /data/builds/10.6_dbg_san/sql/sql_select.cc:20547
 
    #15 0x55e4bc18420a in do_select /data/builds/10.6_dbg_san/sql/sql_select.cc:20151
 
    #16 0x55e4bc18420a in JOIN::exec_inner() /data/builds/10.6_dbg_san/sql/sql_select.cc:4476
 
    #17 0x55e4bc18596c in JOIN::exec() /data/builds/10.6_dbg_san/sql/sql_select.cc:4256
 
    #18 0x55e4bc176a97 in mysql_select(THD*, TABLE_LIST*, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) /data/builds/10.6_dbg_san/sql/sql_select.cc:4672
 
    #19 0x55e4bc17846b in handle_select(THD*, LEX*, select_result*, unsigned long) /data/builds/10.6_dbg_san/sql/sql_select.cc:417
 
    #20 0x55e4bbd89ab2 in execute_sqlcom_select /data/builds/10.6_dbg_san/sql/sql_parse.cc:6133
 
    #21 0x55e4bbdea948 in mysql_execute_command(THD*) /data/builds/10.6_dbg_san/sql/sql_parse.cc:3829
 
    #22 0x55e4bbd4e2ea in mysql_parse(THD*, char*, unsigned int, Parser_state*) /data/builds/10.6_dbg_san/sql/sql_parse.cc:7901
 
    #23 0x55e4bbdbd012 in dispatch_command(enum_server_command, THD*, char*, unsigned int) /data/builds/10.6_dbg_san/sql/sql_parse.cc:1833
 
    #24 0x55e4bbdd25e4 in do_command(THD*) /data/builds/10.6_dbg_san/sql/sql_parse.cc:1365
 
    #25 0x55e4bc7ba5bc in do_handle_one_connection(CONNECT*, bool) /data/builds/10.6_dbg_san/sql/sql_connect.cc:1410
 
    #26 0x55e4bc7bd83f in handle_one_connection /data/builds/10.6_dbg_san/sql/sql_connect.cc:1312
 
    #27 0x55e4becbe631 in pfs_spawn_thread /data/builds/10.6_dbg_san/storage/perfschema/pfs.cc:2201
 
    #28 0x14d364474608 in start_thread /build/glibc-eX1tMB/glibc-2.31/nptl/pthread_create.c:477
 
    #29 0x14d3635c8292 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x122292)
 
 
 
210427 10:18:54 [ERROR] mysqld got signal 11 ;

10.5.9 927a882341eb1087e71d64de4e8cd89ab520de89 (Optimized)

 
2021-04-27 10:45:26 0 [Note] /test/UBASAN_MD260121-mariadb-10.5.9-linux-x86_64-opt/bin/mysqld: ready for connections.
 
Version: '10.5.9-MariaDB'  socket: '/test/UBASAN_MD260121-mariadb-10.5.9-linux-x86_64-opt/socket.sock'  port: 10430  MariaDB Server
 
/data/builds/10.5_opt_san/sql/handler.cc:6343:40: runtime error: member call on null pointer of type 'struct Item'
 
    #0 0x559eb15ee1c9 in handler_index_cond_check /data/builds/10.5_opt_san/sql/handler.cc:6343
 
    #1 0x559eb37b9c9d in row_search_idx_cond_check /data/builds/10.5_opt_san/storage/innobase/row/row0sel.cc:3965
 
    #2 0x559eb37de8f3 in row_search_mvcc(unsigned char*, page_cur_mode_t, row_prebuilt_t*, unsigned long, unsigned long) /data/builds/10.5_opt_san/storage/innobase/row/row0sel.cc:5265
 
    #3 0x559eb313635b in ha_innobase::index_read(unsigned char*, unsigned char const*, unsigned int, ha_rkey_function) /data/builds/10.5_opt_san/storage/innobase/handler/ha_innodb.cc:8758
 
    #4 0x559eb313854e in ha_innobase::index_first(unsigned char*) /data/builds/10.5_opt_san/storage/innobase/handler/ha_innodb.cc:9119
 
    #5 0x559eb313854e in ha_innobase::rnd_next(unsigned char*) /data/builds/10.5_opt_san/storage/innobase/handler/ha_innodb.cc:9212
 
    #6 0x559eb15b4f59 in handler::ha_rnd_next(unsigned char*) /data/builds/10.5_opt_san/sql/handler.cc:3066
 
    #7 0x559eb2369b18 in rr_sequential(READ_RECORD*) /data/builds/10.5_opt_san/sql/records.cc:519
 
    #8 0x559eb0d01b87 in JOIN_CACHE::join_matching_records(bool) /data/builds/10.5_opt_san/sql/sql_join_cache.cc:2261
 
    #9 0x559eb0cfdd07 in JOIN_CACHE::join_records(bool) /data/builds/10.5_opt_san/sql/sql_join_cache.cc:2093
 
    #10 0x559eb0536811 in sub_select_cache(JOIN*, st_join_table*, bool) /data/builds/10.5_opt_san/sql/sql_select.cc:20405
 
    #11 0x559eb06af396 in do_select /data/builds/10.5_opt_san/sql/sql_select.cc:20167
 
    #12 0x559eb06af396 in JOIN::exec_inner() /data/builds/10.5_opt_san/sql/sql_select.cc:4466
 
    #13 0x559eb06b2c69 in JOIN::exec() /data/builds/10.5_opt_san/sql/sql_select.cc:4246
 
    #14 0x559eb06a37fd in mysql_select(THD*, TABLE_LIST*, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) /data/builds/10.5_opt_san/sql/sql_select.cc:4662
 
    #15 0x559eb06a8a93 in handle_select(THD*, LEX*, select_result*, unsigned long) /data/builds/10.5_opt_san/sql/sql_select.cc:417
 
    #16 0x559eb0367a81 in execute_sqlcom_select /data/builds/10.5_opt_san/sql/sql_parse.cc:6281
 
    #17 0x559eb03aafa2 in mysql_execute_command(THD*) /data/builds/10.5_opt_san/sql/sql_parse.cc:3977
 
    #18 0x559eb03351b7 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /data/builds/10.5_opt_san/sql/sql_parse.cc:8062
 
    #19 0x559eb038ea31 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /data/builds/10.5_opt_san/sql/sql_parse.cc:1889
 
    #20 0x559eb039b5d9 in do_command(THD*) /data/builds/10.5_opt_san/sql/sql_parse.cc:1370
 
    #21 0x559eb0b8fe2c in do_handle_one_connection(CONNECT*, bool) /data/builds/10.5_opt_san/sql/sql_connect.cc:1410
 
    #22 0x559eb0b92b64 in handle_one_connection /data/builds/10.5_opt_san/sql/sql_connect.cc:1312
 
    #23 0x559eb2ba454a in pfs_spawn_thread /data/builds/10.5_opt_san/storage/perfschema/pfs.cc:2201
 
    #24 0x152c8eb49608 in start_thread /build/glibc-eX1tMB/glibc-2.31/nptl/pthread_create.c:477
 
    #25 0x152c8dc9d292 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x122292)
 
 
 
210427 10:45:32 [ERROR] mysqld got signal 11 ;

Confirmed that neither 10.3.28 75538f94ca06915ddc22458b82b8e148e51dd0db (Debug) nor 10.4.19 e626f511f9dc4faee9ae98fb5a8c8c6ddd06679b (Debug) produces an ASAN trace. The 10.4 output is as follows:

10.4.18 e626f511f9dc4faee9ae98fb5a8c8c6ddd06679b (Debug)

 
10.4.19-dbg>SELECT * FROM t,t AS b WHERE t.c=0 AND t.d=b.c AND t.c=b.d;
 
+------+------+------+------+
 
| c    | d    | c    | d    |
 
+------+------+------+------+
 
|    0 |    0 |    0 |    0 |
 
+------+------+------+------+
 
1 row in set (0.002 sec)



 Comments   
Comment by Oleg Smirnov [ 2022-05-07 ]

psergei, is it possible to combine a hash join algorithm (BNLH) with the Rowid Filtering Optimization? I doubt it's possible since hash join uses full table scan and not an index access.

Explain plan for hash join enabled and rowid_filter disabled:

MariaDB [test]> set optimizer_switch='<...skipped...> rowid_filter=off <...skipped...> ';
 
 
 
MariaDB [test]> SET join_cache_level=4;
 
 
 
MariaDB [test]> explain SELECT * FROM t,t AS b WHERE t.c=0 AND t.d=b.c AND t.c=b.d;
 
+------+-------------+-------+----------+---------------+---------+---------+----------+------+--------------------------------------------------+
 
| id   | select_type | table | type     | possible_keys | key     | key_len | ref      | rows | Extra                                            |
 
+------+-------------+-------+----------+---------------+---------+---------+----------+------+--------------------------------------------------+
 
|    1 | SIMPLE      | t     | ref      | c,d           | c       | 9       | const    | 1    | Using where                                      |
 
|    1 | SIMPLE      | b     | hash_ALL | c,d           | #hash#c | 9       | test.t.d | 7    | Using where; Using join buffer (flat, BNLH join) |
 
+------+-------------+-------+----------+---------------+---------+---------+----------+------+--------------------------------------------------+

For hash join and rowid_filter enabled:

MariaDB [test]> set optimizer_switch='<...skipped...> rowid_filter=on <...skipped...> ';
 
 
 
MariaDB [test]> explain SELECT * FROM t,t AS b WHERE t.c=0 AND t.d=b.c AND t.c=b.d;
 
+------+-------------+-------+-----------------+---------------+-----------+---------+----------+---------+----------------------------------------------------------------------+
 
| id   | select_type | table | type            | possible_keys | key       | key_len | ref      | rows    | Extra                                                                |
 
+------+-------------+-------+-----------------+---------------+-----------+---------+----------+---------+----------------------------------------------------------------------+
 
|    1 | SIMPLE      | t     | ref             | c,d           | c         | 9       | const    | 1       | Using where                                                          |
 
|    1 | SIMPLE      | b     | hash_ALL|filter | c,d           | #hash#c|d | 9|5     | test.t.d | 7 (57%) | Using where; Using join buffer (flat, BNLH join); Using rowid filter |
 
+------+-------------+-------+-----------------+---------------+-----------+---------+----------+---------+----------------------------------------------------------------------+

For hash join disabled and rowid_filter enabled:

MariaDB [test]> SET join_cache_level=2;
 
 
 
MariaDB [test]> explain SELECT * FROM t,t AS b WHERE t.c=0 AND t.d=b.c AND t.c=b.d;
 
+------+-------------+-------+------------+---------------+------+---------+----------+---------+--------------------------------------------------------+
 
| id   | select_type | table | type       | possible_keys | key  | key_len | ref      | rows    | Extra                                                  |
 
+------+-------------+-------+------------+---------------+------+---------+----------+---------+--------------------------------------------------------+
 
|    1 | SIMPLE      | t     | ref        | c,d           | c    | 9       | const    | 1       | Using where                                            |
 
|    1 | SIMPLE      | b     | ref|filter | c,d           | c|d  | 9|5     | test.t.d | 1 (57%) | Using index condition; Using where; Using rowid filter |
 
+------+-------------+-------+------------+---------------+------+---------+----------+---------+--------------------------------------------------------+

Comment by Oleg Smirnov [ 2022-05-22 ]

As far as I could figure out the problem in this code:

storage/innobase/row/row0sel.cc 10.5

 
...
 
4021    check_result_t result = prebuilt->idx_cond
 
4022		? handler_index_cond_check(prebuilt->idx_cond)
 
4023		: CHECK_POS;
 
...

We have 

prebuilt->idx_cond != NULL

but 

((handler*)(prebuilt->idx_cond))->pushed_idx_cond == NULL

. pushed_idx_cond is dereferenced at handler_index_cond_check and since it is NULL there goes the crash.

I assume the following condition must be satisfied: 

DBUG_ASSERT(!prebuilt->idx_cond ||
 
                (prebuilt->idx_cond && ((handler*)(prebuilt->idx_cond))->pushed_idx_cond));


With this assertion added to the code all tests from the main suite pass successfully.

But I couldn't yet figure out why pushed_idx_cond==NULL while idx_cond != NULL.

Comment by Sergei Petrunia [ 2022-05-23 ]

> But I couldn't yet figure out why pushed_idx_cond==NULL while idx_cond != NULL.

This doesn't look like a valids state to me. InnoDB internals think that pushed index condition is present (prebuilt->idx_cond ) while class handler thinks it is not ( handler->pushed_idx_cond==NULL ).

But I also think it is trying to construct an invalid query where it uses full table scan (right, full table scan. The one that's performed with h->ha_rnd_next() call) and ALSO uses a rowid filter.

Comment by Sergei Petrunia [ 2022-05-23 ]

Analysis.

Debugging the testcase I see the following happens:

Step1. The join optimizer generates a query plan.
The join order is "t, b". b uses ref access and also rowid filter.

Relevant piece of the trace:

      "plan_prefix": ["t"],
 
      "table": "b",
 
      "best_access_path": {
 
        {
 
          "access_type": "ref",
 
          "index": "c",
 
          "used_range_estimates": false,
 
          "cause": "not available",
 
          "rowid_filter_key": "d",
 
          "rows": 2,
 
          "cost": 2.229080927,
 
          "chosen": true
 
        },
 
 
 
        "chosen_access_method": {
 
          "type": "ref",
 
          "records": 2,
 
          "cost": 2.229080927,
 
          "uses_join_buffering": false,
 
          "rowid_filter_key": "d"
 
        }
 
      },

Step 2: Then, we reach check_join_cache_usage(table "b")

This piece of code "initiates" a switch from using ref access 

    if ((cache_level <=4 && !no_hashed_cache) || no_bka_cache ||
 
        tab->is_ref_for_hash_join() ||
 
	((flags & HA_MRR_NO_ASSOCIATION) && cache_level <=6))
 
    {
 
      if (!tab->hash_join_is_possible() ||
 
          tab->make_scan_filter())
 
        goto no_join_cache;
 
      if (cache_level == 3)
 
        prev_cache= 0;
 
      if ((tab->cache= new (root) JOIN_CACHE_BNLH(join, tab, prev_cache)))
 
      {
 
        tab->icp_other_tables_ok= FALSE;        
        return (4 - MY_TEST(!prev_cache));
 
      }

and this code in make_join_readinfo() finishes it:

    if (tab->cache && tab->cache->get_join_alg() == JOIN_CACHE::BNLH_JOIN_ALG)
 
      tab->type= JT_HASH;

Note that all this code is called when
join_tab->range_rowid_filter_info and join_tab->rowid_filter are already initialized,
and it doesn't clear either of these.

Step 3: At execution phase, we populate the rowid filter.
Then, Rowid filter code in Range_rowid_filter::fill() activates the filter:

  table->file->rowid_filter_is_active= true;

Then, the table is initialized with ha_innobase::rnd_init() for doing a full table scan.
Note this check in ha_innobase::build_template():

	if ((active_index != MAX_KEY
 
	     && active_index == pushed_idx_cond_keyno)
 
	    || (pushed_rowid_filter && rowid_filter_is_active)) {
 
		/* Push down an index condition or an end_range check. */
 
        ...
 
		if (active_index == pushed_idx_cond_keyno) {
 
			m_prebuilt->idx_cond = this;
 
		}
 
	}

This part of the condition is satisfied:

   (pushed_rowid_filter && rowid_filter_is_active)

despite that active_index==MAX_KEY, and we assign m_prebuilt->idx_cond. Even if there was
never a pushed index condition.

On execution, we arrive at row_search_idx_cond_check(), which assumes that
prebuilt->idx_cond!=NULL means one can call handler_index_cond_check(). It calls it
and crashes.

Comment by Sergei Petrunia [ 2022-05-23 ]

The obvious fix for the assert we're hitting:
change this:

		if (active_index == pushed_idx_cond_keyno) {
 
			m_prebuilt->idx_cond = this;
 
		}

to use this condition:

if (active_index == pushed_idx_cond_keyno && active_index != MAX_KEY)

Then, need to remove rowid filtering if we're going to use ref access.

Comment by Oleg Smirnov [ 2022-05-24 ]

I already tried such fix but it leads to the crash at another place:

mariadbd: /home/oleg/10.5/server/storage/innobase/row/row0sel.cc:4032: check_result_t row_search_idx_cond_check(byte*, row_prebuilt_t*, const rec_t*, const rec_offs*): Assertion `!prebuilt->index->is_primary()' failed.
 
220524  9:08:45 [ERROR] mysqld got signal 6 ;
 
This could be because you hit a bug. It is also possible that this binary
 
or one of the libraries it was linked against is corrupt, improperly built,
 
or misconfigured. This error can also be caused by malfunctioning hardware.
 
 
 
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
 
 
We will try our best to scrape up some info that will hopefully help
 
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.
 
 
 
Server version: 10.5.16-MariaDB-debug
 
key_buffer_size=134217728
 
read_buffer_size=131072
 
max_used_connections=1
 
max_threads=153
 
thread_count=1
 
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467978 K  bytes of memory
 
Hope that's ok; if not, decrease some variables in the equation.
 
 
 
Thread pointer: 0x7f73c8000dc8
 
Attempting backtrace. You can use the following information to find out
 
where mysqld died. If you see no messages after this, something went
 
terribly wrong...
 
stack_bottom = 0x7f742ce5bd78 thread_stack 0x49000
 
addr2line: './sql/mariadbd': No such file
 
Printing to addr2line failed
 
./sql/mariadbd(my_print_stacktrace+0x44)[0x55f7c01784a8]
 
./sql/mariadbd(handle_fatal_signal+0x42b)[0x55f7bf807e3b]
 
libc_sigaction.c:0(__restore_rt)[0x7f742fc71520]
 
nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7f742fcc5a7c]
 
posix/raise.c:27(__GI_raise)[0x7f742fc71476]
 
stdlib/abort.c:81(__GI_abort)[0x7f742fc577f3]
 
intl/loadmsgcat.c:1177(_nl_load_domain)[0x7f742fc5771b]
 
:0(__GI___assert_fail)[0x7f742fc68e96]
 
addr2line: './sql/mariadbd': No such file
 
./sql/mariadbd(+0x136091d)[0x55f7bfe7e91d]
 
./sql/mariadbd(+0x1364e5e)[0x55f7bfe82e5e]
 
./sql/mariadbd(+0x1144743)[0x55f7bfc62743]
 
./sql/mariadbd(+0x11457f8)[0x55f7bfc637f8]
 
./sql/mariadbd(+0x11459f0)[0x55f7bfc639f0]
 
./sql/mariadbd(_ZN7handler11ha_rnd_nextEPh+0x495)[0x55f7bf812ff9]
 
./sql/mariadbd(_Z13rr_sequentialP11READ_RECORD+0x34)[0x55f7bf9e4dfa]
 
./sql/mariadbd(_ZN11READ_RECORD11read_recordEv+0x21)[0x55f7bf3c351d]
 
./sql/mariadbd(_Z21join_init_read_recordP13st_join_table+0x252)[0x55f7bf50d0ea]
 
./sql/mariadbd(_ZN13JOIN_TAB_SCAN4openEv+0x56)[0x55f7bf693b48]
 
./sql/mariadbd(_ZN10JOIN_CACHE21join_matching_recordsEb+0x1cf)[0x55f7bf691e09]
 
./sql/mariadbd(_ZN10JOIN_CACHE12join_recordsEb+0xf7)[0x55f7bf691891]
 
./sql/mariadbd(_Z16sub_select_cacheP4JOINP13st_join_tableb+0xf8)[0x55f7bf50a6a7]
 
./sql/mariadbd(_Z10sub_selectP4JOINP13st_join_tableb+0xc7)[0x55f7bf50a8c1]
 
./sql/mariadbd(+0x9ebf62)[0x55f7bf509f62]
 
./sql/mariadbd(_ZN4JOIN10exec_innerEv+0xe8b)[0x55f7bf4dc791]
 
./sql/mariadbd(_ZN4JOIN4execEv+0xe5)[0x55f7bf4db853]
 
./sql/mariadbd(_Z12mysql_selectP3THDP10TABLE_LISTR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x374)[0x55f7bf4dd134]
 
./sql/mariadbd(_Z13handle_selectP3THDP3LEXP13select_resultm+0x196)[0x55f7bf4cc5c6]
 
./sql/mariadbd(+0x96e9bd)[0x55f7bf48c9bd]
 
./sql/mariadbd(_Z21mysql_execute_commandP3THD+0x1496)[0x55f7bf483a0f]
 
./sql/mariadbd(_Z11mysql_parseP3THDPcjP12Parser_statebb+0x2f8)[0x55f7bf491a3c]
 
./sql/mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x1153)[0x55f7bf47d280]
 
./sql/mariadbd(_Z10do_commandP3THD+0x853)[0x55f7bf47b968]
 
./sql/mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x242)[0x55f7bf6368c9]
 
./sql/mariadbd(handle_one_connection+0x5f)[0x55f7bf63657e]
 
./sql/mariadbd(+0x105db22)[0x55f7bfb7bb22]
 
nptl/pthread_create.c:442(start_thread)[0x7f742fcc3b43]
 
x86_64/clone3.S:83(__clone3)[0x7f742fd55a00]

Another few ideas to discuss.

1. Reset rowid filter when full table hash join is employed:

diff --git a/sql/sql_select.cc b/sql/sql_select.cc
 
index 192c3285ba6..b4ddadf4f2a 100644
 
--- a/sql/sql_select.cc
 
+++ b/sql/sql_select.cc
 
@@ -13309,7 +13309,11 @@ make_join_readinfo(JOIN *join, ulonglong options, uint no_jbuf_after)
 
        tab[-1].next_select=sub_select_cache;
 
 
     if (tab->cache && tab->cache->get_join_alg() == JOIN_CACHE::BNLH_JOIN_ALG)
 
-      tab->type= JT_HASH;
 
+    {
 
+        tab->type= JT_HASH;
 
+        tab->range_rowid_filter_info= NULL;
 
+        tab->rowid_filter= NULL;
 
+    }
 
       
     switch (tab->type) {
 
     case JT_SYSTEM:                            // Only happens with left join

This seem to break only a couple of test cases from join_cache.test where hash_ALL|filter was chosen as the joining method.
But there is no cost re-calculation is this scenario so how can we be sure hash_ALL will perform better than ref|filter combination?
So there's another idea:

2. Do not employ hash join if there is rowid_filter previously set on the table:

diff --git a/sql/sql_select.cc b/sql/sql_select.cc
 
index 192c3285ba6..0b53d39db95 100644
 
--- a/sql/sql_select.cc
 
+++ b/sql/sql_select.cc
 
@@ -9976,7 +9976,7 @@ int JOIN_TAB::make_scan_filter()
 
 
 bool JOIN_TAB::hash_join_is_possible()
 
 {
 
-  if (type != JT_REF && type != JT_EQ_REF)
 
+  if ((type != JT_REF && type != JT_EQ_REF) || rowid_filter)
 
     return FALSE;
 
   if (!is_ref_for_hash_join())
 
   {

The same test cases from join_cache.test break, but now due to change from "hash_ALL|filter" to "ref|filter".

Comment by Sergei Petrunia [ 2022-05-24 ]

oleg.smirnov,

I already tried such fix but it leads to the crash at another place:

Right. Now the crash is "correct" - we hit an assert because we're trying to use a rowid filter on a clustered PK.

1. Reset rowid filter when full table hash join is employed:

I think that

  • The choice doesn't matter much. This code path does an unconditional switch to using hash join regardless of what access method was picked by best_access_path. AFAIU it was only intended for testing, not for real use.

2. We can use option #1: Reset rowid filter when full table hash join is employed

Comment by Oleg Smirnov [ 2022-05-25 ]

Pushed the fix discussed to a new branch bb-10.5-MDEV-27366-2.

Comment by Oleg Smirnov [ 2022-05-26 ]

Fixed the issue with "delete", force-pushed into the last branch bb-10.5-MDEV-27366-2. Some buildbot tests have failed (https://buildbot.askmonty.org/buildbot/grid?category=main&branch=bb-10.5-MDEV-27366-2) but they don't look related to the patch.

Comment by Sergei Petrunia [ 2022-06-01 ]

Studying the changes to join_cache.result in the patch... posted details about one of them to MDEV-28712.

Comment by Sergei Petrunia [ 2022-06-01 ]

Questions to discuss:

  • Is it better to remove rowid filter in check_join_cache_usage() or in make_join_readinfo()?
  • Can we add optimizer trace coverage for the changes that are made to the query plan?
Comment by Oleg Smirnov [ 2022-06-04 ]
  1. Filed a new Jira task for InnoDB fix: MDEV-28747;
  2. Moved the Rowid Filter discarding to check_join_cache_usage_for_tables() though it has required adding another iteration through JOIN tables
  3. During the call we decided that optimizer trace enhancement is out of scope of this task.
Comment by Roel Van de Paar [ 2022-06-05 ]

I did an updated test of versions affected

Bug confirmed present in:
MariaDB: 10.5.17 (dbg), 10.5.17 (opt), 10.6.9 (dbg), 10.6.9 (opt), 10.7.5 (dbg), 10.7.5 (opt), 10.8.4 (dbg), 10.8.4 (opt), 10.9.2 (dbg), 10.9.2 (opt), 10.10.0 (dbg), 10.10.0 (opt)

Bug (or feature/syntax) confirmed not present in:
MariaDB: 10.3.36 (dbg), 10.3.36 (opt), 10.4.26 (dbg), 10.4.26 (opt)
MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.51 (dbg), 5.6.51 (opt), 5.7.38 (dbg), 5.7.38 (opt), 8.0.29 (dbg), 8.0.29 (opt)

Comment by Roel Van de Paar [ 2023-09-28 ]

An additional testcase leading to a somewhat different stack and an assert seen in MDEV-27292.

SET sql_mode='';
 
SET JOIN_cache_level=4;
 
CREATE TABLE t (a INT,b CHAR(1),d CHAR(1),c INT,INDEX (a),INDEX (b),UNIQUE INDEX (d));
 
REPLACE INTO t (a) VALUES (1),(1);
 
INSERT INTO t VALUES (0,0,9165,0);
 
INSERT INTO t VALUES (0,0,6210,0);
 
INSERT INTO t (b) VALUES (1);
 
INSERT INTO t VALUES (0,0,2125,0);
 
SELECT * FROM t NATURAL JOIN (SELECT * FROM t) a WHERE b>'';

Leads to:

10.6.16 076df87b4c1dc5123d66600b82201050c45aa9d9 (Debug)

 
mariadbd: /test/10.6_dbg/storage/innobase/row/row0sel.cc:4083: check_result_t row_search_idx_cond_check(byte*, row_prebuilt_t*, const rec_t*, const rec_offs*): Assertion `!prebuilt->index->is_primary()' failed.

10.6.16 076df87b4c1dc5123d66600b82201050c45aa9d9 (Debug)

 
Core was generated by `/test/MD270923-mariadb-10.6.16-linux-x86_64-dbg/bin/mariadbd --no-defaults --co'.
 
Program terminated with signal SIGABRT, Aborted.
 
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=22797025109568)
 
    at ./nptl/pthread_kill.c:44
 
[Current thread is 1 (Thread 0x14bbd8956640 (LWP 3818310))]
 
(gdb) bt
 
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=22797025109568) at ./nptl/pthread_kill.c:44
 
#1  __pthread_kill_internal (signo=6, threadid=22797025109568) at ./nptl/pthread_kill.c:78
 
#2  __GI___pthread_kill (threadid=22797025109568, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
 
#3  0x000014bbe4242476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
 
#4  0x000014bbe42287f3 in __GI_abort () at ./stdlib/abort.c:79
 
#5  0x000014bbe422871b in __assert_fail_base (fmt=0x14bbe43dd150 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55d977701ae8 "!prebuilt->index->is_primary()", file=0x55d977700fa8 "/test/10.6_dbg/storage/innobase/row/row0sel.cc", line=4083, function=<optimized out>) at ./assert/assert.c:92
 
#6  0x000014bbe4239e96 in __GI___assert_fail (assertion=0x55d977701ae8 "!prebuilt->index->is_primary()", file=0x55d977700fa8 "/test/10.6_dbg/storage/innobase/row/row0sel.cc", line=4083, function=0x55d977701a88 "check_result_t row_search_idx_cond_check(byte*, row_prebuilt_t*, const rec_t*, const rec_offs*)") at ./assert/assert.c:101
 
#7  0x000055d97708ae60 in row_search_idx_cond_check (mysql_rec=mysql_rec@entry=0x14bb8c070178 "\375\001", prebuilt=prebuilt@entry=0x14bb8c071208, rec=rec@entry=0x14bbc066007e "", offsets=0x14bbd8953670) at /test/10.6_dbg/storage/innobase/row/row0sel.cc:4083
 
#8  0x000055d977095c23 in row_search_mvcc (buf=buf@entry=0x14bb8c070178 "\375\001", mode=<optimized out>, prebuilt=<optimized out>, match_mode=<optimized out>, direction=direction@entry=0) at /test/10.6_dbg/storage/innobase/row/row0sel.cc:5469
 
#9  0x000055d976eff962 in ha_innobase::index_read (this=this@entry=0x14bb8c070570, buf=0x14bb8c070178 "\375\001", key_ptr=key_ptr@entry=0x0, key_len=key_len@entry=0, find_flag=find_flag@entry=HA_READ_AFTER_KEY) at /test/10.6_dbg/storage/innobase/handler/ha_innodb.cc:9122
 
#10 0x000055d976effbb1 in ha_innobase::index_first (this=this@entry=0x14bb8c070570, buf=<optimized out>) at /test/10.6_dbg/storage/innobase/handler/ha_innodb.cc:9492
 
#11 0x000055d976f00082 in ha_innobase::rnd_next (this=0x14bb8c070570, buf=<optimized out>) at /test/10.6_dbg/storage/innobase/handler/ha_innodb.cc:9584
 
#12 0x000055d976b60056 in handler::ha_rnd_next (this=0x14bb8c070570, buf=0x14bb8c070178 "\375\001") at /test/10.6_dbg/sql/handler.cc:3460
 
#13 0x000055d976d094f8 in rr_sequential (info=0x14bb8c078748) at /test/10.6_dbg/sql/records.cc:519
 
#14 0x000055d976904797 in READ_RECORD::read_record (this=0x14bb8c078748) at /test/10.6_dbg/sql/records.h:81
 
#15 join_init_read_record (tab=0x14bb8c078670) at /test/10.6_dbg/sql/sql_select.cc:22697
 
#16 0x000055d976a30d11 in JOIN_TAB_SCAN::open (this=0x14bb8c07aa80) at /test/10.6_dbg/sql/sql_join_cache.cc:3489
 
#17 0x000055d976a34142 in JOIN_CACHE::join_matching_records (this=0x14bb8c07a8d8, skip_last=false) at /test/10.6_dbg/sql/sql_join_cache.cc:2350
 
#18 0x000055d976a33db8 in JOIN_CACHE::join_records (this=this@entry=0x14bb8c07a8d8, skip_last=skip_last@entry=false) at /test/10.6_dbg/sql/sql_join_cache.cc:2176
 
#19 0x000055d9768f0006 in sub_select_cache (join=0x14bb8c017220, join_tab=0x14bb8c078670, end_of_records=<optimized out>) at /test/10.6_dbg/sql/sql_select.cc:21462
 
#20 0x000055d9768efb4b in sub_select (join=0x14bb8c017220, join_tab=0x14bb8c0782b0, end_of_records=true) at /test/10.6_dbg/sql/sql_select.cc:21646
 
#21 0x000055d976921380 in do_select (procedure=<optimized out>, join=0x14bb8c017220) at /test/10.6_dbg/sql/sql_select.cc:21235
 
#22 JOIN::exec_inner (this=this@entry=0x14bb8c017220) at /test/10.6_dbg/sql/sql_select.cc:4834
 
#23 0x000055d9769218bc in JOIN::exec (this=this@entry=0x14bb8c017220) at /test/10.6_dbg/sql/sql_select.cc:4612
 
#24 0x000055d97691f794 in mysql_select (thd=thd@entry=0x14bb8c000d58, tables=0x14bb8c0139c0, fields=@0x14bb8c013660: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x14bb8c013978, last = 0x14bb8c074e38, elements = 4}, <No data fields>}, conds=0x14bb8c0166e0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x14bb8c0171f8, unit=0x14bb8c005100, select_lex=0x14bb8c0133a8) at /test/10.6_dbg/sql/sql_select.cc:5091
 
#25 0x000055d97691ff8e in handle_select (thd=thd@entry=0x14bb8c000d58, lex=lex@entry=0x14bb8c005038, result=result@entry=0x14bb8c0171f8, setup_tables_done_option=setup_tables_done_option@entry=0) at /test/10.6_dbg/sql/sql_select.cc:559
 
#26 0x000055d97689971c in execute_sqlcom_select (thd=thd@entry=0x14bb8c000d58, all_tables=0x14bb8c0139c0) at /test/10.6_dbg/sql/sql_parse.cc:6285
 
#27 0x000055d9768a4d50 in mysql_execute_command (thd=thd@entry=0x14bb8c000d58, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/10.6_dbg/sql/sql_parse.cc:3961
 
#28 0x000055d9768ac164 in mysql_parse (thd=thd@entry=0x14bb8c000d58, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x14bbd89551f0) at /test/10.6_dbg/sql/sql_parse.cc:8050
 
#29 0x000055d9768ae4da in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x14bb8c000d58, packet=packet@entry=0x14bb8c00af29 "", packet_length=packet_length@entry=59, blocking=blocking@entry=true) at /test/10.6_dbg/sql/sql_class.h:241
 
#30 0x000055d9768b05f7 in do_command (thd=0x14bb8c000d58, blocking=blocking@entry=true) at /test/10.6_dbg/sql/sql_parse.cc:1409
 
#31 0x000055d9769ef1fd in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55d97a451fe8, put_in_cache=put_in_cache@entry=true) at /test/10.6_dbg/sql/sql_connect.cc:1416
 
#32 0x000055d9769ef4f2 in handle_one_connection (arg=arg@entry=0x55d97a451fe8) at /test/10.6_dbg/sql/sql_connect.cc:1318
 
#33 0x000055d976e3b08c in pfs_spawn_thread (arg=0x55d97a43ff98) at /test/10.6_dbg/storage/perfschema/pfs.cc:2201
 
#34 0x000014bbe4294b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
 
#35 0x000014bbe4326a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Bug confirmed present in:
MariaDB: 10.5.23 (dbg), 10.6.16 (dbg), 10.9.8 (dbg), 10.10.7 (dbg), 10.11.6 (dbg)

Bug (or feature/syntax) confirmed not present in:
MariaDB: 10.4.32 (dbg), 10.4.32 (opt), 10.5.23 (opt), 10.6.16 (opt), 10.9.8 (opt), 10.10.7 (opt), 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 (dbg), 11.3.0 (opt)
MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.51 (dbg), 5.6.51 (opt), 5.7.40 (dbg), 8.0.33 (dbg), 8.0.33 (opt)

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