[MDEV-30651] Crash after killing query while it is processed by test_quick_select - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Critical
Resolution: Fixed
Affects Version/s: 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11, 11.0(EOL)
Fix Version/s: 10.5.26, 10.6.19, 10.11.9, 11.1.6, 11.2.5, 11.4.3, 11.5.2
Component/s: Optimizer, Storage Engine - MyISAM
Labels:
- not-11.1+
- race
- sporadic

Description

Somewhat similar to ~~MDEV-19720~~ (same assert) however the testcase from that bug no longer produces any crash (on any version - tested), while this crashes 10.5-11.0, and this testcase needs max_statement_time. Finally, this bug is present in 10.5+ only. Testcase is sporadic. Requires from 2 to 200 executions before triggering. Possible race, though it could just be the result of the timing.

SET storage_engine=MyISAM, sql_mode='';

CREATE TABLE t (c1 INT KEY,c2 INT,c3 TIME,INDEX (c2));

INSERT INTO t VALUES (0,0,0),(1000,0,0);

EXECUTE x;

SET @@max_statement_time=0.0001;

SELECT * FROM t WHERE c1 >='00:00:00' AND c1 <'23:00:00' AND c2='13:13:13';

DROP TABLE t;

Leads to:

11.0.1 4d09050ca77a7efac4565d46e4bcd85a5f210c53 (Optimized)
Core was generated by `/test/MD110223-mariadb-11.0.1-linux-x86_64-opt/bin/mysqld --no-defaults --core-'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 st_join_table::save_explain_data (this=0x148ee808be30, eta=0x148ee808d250,
prefix_tables=<optimized out>, distinct_arg=<optimized out>,
first_top_tab=0x148ee808be30) at /test/11.0_opt/sql/sql_select.cc:27921
[Current thread is 1 (Thread 0x148f34b46640 (LWP 571587))]
(gdb) bt
#0 st_join_table::save_explain_data (this=0x148ee808be30, eta=0x148ee808d250, prefix_tables=<optimized out>, distinct_arg=<optimized out>, first_top_tab=0x148ee808be30) at /test/11.0_opt/sql/sql_select.cc:27921
#1 0x000055ef3ec6d999 in JOIN::save_explain_data_intern (this=0x148ee8012b78, output=0x148ee8013160, need_tmp_table_arg=<optimized out>, need_order_arg=<optimized out>, distinct_arg=false, message=<optimized out>) at /test/11.0_opt/sql/sql_select.cc:28480
#2 0x000055ef3ec6dc68 in JOIN::save_explain_data (this=0x148ee8012b78, output=0x148ee8013160, can_overwrite=<optimized out>, need_tmp_table=<optimized out>, need_order=<optimized out>, distinct=<optimized out>) at /test/11.0_opt/sql/sql_select.cc:4559
#3 0x000055ef3ec6dd44 in JOIN::build_explain (this=this@entry=0x148ee8012b78) at /test/11.0_opt/sql/sql_select.cc:1816
#4 0x000055ef3ec78a5a in JOIN::optimize (this=this@entry=0x148ee8012b78) at /test/11.0_opt/sql/sql_select.cc:1876
#5 0x000055ef3ec78b5e in mysql_select (thd=0x148ee8000c68, tables=0x148ee8010e48, fields=@0x148ee8010b08: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x148ee8010e00, last = 0x148ee80136d0, elements = 3}, <No data fields>}, conds=0x148ee8011d38, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=<optimized out>, result=0x148ee8012b50, unit=0x148ee8004ce8, select_lex=0x148ee8010868) at /test/11.0_opt/sql/sql_select.cc:5066
#6 0x000055ef3ec792f4 in handle_select (thd=thd@entry=0x148ee8000c68, lex=lex@entry=0x148ee8004c10, result=result@entry=0x148ee8012b50, setup_tables_done_option=setup_tables_done_option@entry=0) at /test/11.0_opt/sql/sql_select.cc:581
#7 0x000055ef3ebf4725 in execute_sqlcom_select (thd=0x148ee8000c68, all_tables=0x148ee8010e48) at /test/11.0_opt/sql/sql_parse.cc:6265
#8 0x000055ef3ec034c0 in mysql_execute_command (thd=0x148ee8000c68, is_called_from_prepared_stmt=<optimized out>) at /test/11.0_opt/sql/sql_parse.cc:3949
#9 0x000055ef3ec04d54 in mysql_parse (rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>, thd=0x148ee8000c68) at /test/11.0_opt/sql/sql_parse.cc:8000
#10 mysql_parse (thd=0x148ee8000c68, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at /test/11.0_opt/sql/sql_parse.cc:7922
#11 0x000055ef3ec07332 in dispatch_command (command=COM_QUERY, thd=0x148ee8000c68, packet=<optimized out>, packet_length=<optimized out>, blocking=<optimized out>) at /test/11.0_opt/sql/sql_parse.cc:1991
#12 0x000055ef3ec08ad0 in do_command (thd=0x148ee8000c68, blocking=blocking@entry=true) at /test/11.0_opt/sql/sql_parse.cc:1407
#13 0x000055ef3ed1eaa7 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55ef411c9f98, put_in_cache=put_in_cache@entry=true) at /test/11.0_opt/sql/sql_connect.cc:1416
#14 0x000055ef3ed1ed7d in handle_one_connection (arg=0x55ef411c9f98) at /test/11.0_opt/sql/sql_connect.cc:1318
#15 0x0000148f4dfeeb43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#16 0x0000148f4e080a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

11.0.1 4d09050ca77a7efac4565d46e4bcd85a5f210c53 (Debug)
mysqld: /test/11.0_dbg/sql/sql_select.cc:1955: bool JOIN::make_range_rowid_filters(): Assertion `sel->quick' failed.

11.0.1 4d09050ca77a7efac4565d46e4bcd85a5f210c53 (Debug)
Core was generated by `/test/MD110223-mariadb-11.0.1-linux-x86_64-dbg/bin/mysqld --no-defaults --core-'.
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=22476463277632)
at ./nptl/pthread_kill.c:44
[Current thread is 1 (Thread 0x1471359c0640 (LWP 571559))]
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=22476463277632) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=22476463277632) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=22476463277632, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x000014715303d476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00001471530237f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x000014715302371b in __assert_fail_base (fmt=0x1471531d8150 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x556e2b1da48d "sel->quick", file=0x556e2b192038 "/test/11.0_dbg/sql/sql_select.cc", line=1955, function=<optimized out>) at ./assert/assert.c:92
#6 0x0000147153034e96 in __GI___assert_fail (assertion=0x556e2b1da48d "sel->quick", file=0x556e2b192038 "/test/11.0_dbg/sql/sql_select.cc", line=1955, function=0x556e2b192bc0 "bool JOIN::make_range_rowid_filters()") at ./assert/assert.c:101
#7 0x0000556e2a6da7ab in JOIN::make_range_rowid_filters (this=this@entry=0x1470e4015538) at /test/11.0_dbg/sql/sql_select.cc:1955
#8 0x0000556e2a70e83d in JOIN::optimize_stage2 (this=this@entry=0x1470e4015538) at /test/11.0_dbg/sql/sql_select.cc:2584
#9 0x0000556e2a7122d2 in JOIN::optimize_inner (this=this@entry=0x1470e4015538) at /test/11.0_dbg/sql/sql_select.cc:2560
#10 0x0000556e2a712770 in JOIN::optimize (this=this@entry=0x1470e4015538) at /test/11.0_dbg/sql/sql_select.cc:1870
#11 0x0000556e2a712860 in mysql_select (thd=thd@entry=0x1470e4000d58, tables=0x1470e4013808, fields=@0x1470e40134c8: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x1470e40137c0, last = 0x1470e40160a0, elements = 3}, <No data fields>}, conds=0x1470e40146f8, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2164525824, result=0x1470e4015510, unit=0x1470e4004f98, select_lex=0x1470e4013228) at /test/11.0_dbg/sql/sql_select.cc:5066
#12 0x0000556e2a713026 in handle_select (thd=thd@entry=0x1470e4000d58, lex=lex@entry=0x1470e4004ec0, result=result@entry=0x1470e4015510, setup_tables_done_option=setup_tables_done_option@entry=0) at /test/11.0_dbg/sql/sql_select.cc:581
#13 0x0000556e2a67df31 in execute_sqlcom_select (thd=thd@entry=0x1470e4000d58, all_tables=0x1470e4013808) at /test/11.0_dbg/sql/sql_parse.cc:6265
#14 0x0000556e2a6893d8 in mysql_execute_command (thd=thd@entry=0x1470e4000d58, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/11.0_dbg/sql/sql_parse.cc:3949
#15 0x0000556e2a6906d0 in mysql_parse (thd=thd@entry=0x1470e4000d58, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x1471359bf2c0) at /test/11.0_dbg/sql/sql_parse.cc:8000
#16 0x0000556e2a692864 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x1470e4000d58, packet=packet@entry=0x1470e400ae09 "SELECT * FROM t WHERE c1 >='00:00:00' AND c1 <'23:00:00' AND c2='13:13:13'", packet_length=packet_length@entry=74, blocking=blocking@entry=true) at /test/11.0_dbg/sql/sql_class.h:242
#17 0x0000556e2a6946bd in do_command (thd=0x1470e4000d58, blocking=blocking@entry=true) at /test/11.0_dbg/sql/sql_parse.cc:1407
#18 0x0000556e2a7df4e4 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x556e2d9bd9e8, put_in_cache=put_in_cache@entry=true) at /test/11.0_dbg/sql/sql_connect.cc:1416
#19 0x0000556e2a7df743 in handle_one_connection (arg=0x556e2d9bd9e8) at /test/11.0_dbg/sql/sql_connect.cc:1318
#20 0x000014715308fb43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#21 0x0000147153121a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Bug confirmed present in:
MariaDB: 10.5.20 (dbg), 10.5.20 (opt), 10.6.13 (dbg), 10.6.13 (opt), 10.7.8 (dbg), 10.7.8 (opt), 10.8.8 (dbg), 10.8.8 (opt), 10.9.6 (dbg), 10.9.6 (opt), 10.10.4 (dbg), 10.10.4 (opt), 10.11.2 (dbg), 10.11.2 (opt), 11.0.1 (dbg), 11.0.1 (opt)

Bug (or feature/syntax) confirmed not present in:
MariaDB: 10.3.38 (dbg), 10.3.38 (opt), 10.4.29 (dbg), 10.4.29 (opt)
MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.51 (dbg), 5.6.51 (opt), 5.7.40 (dbg), 5.7.40 (opt), 8.0.31 (dbg), 8.0.31 (opt)

Attachments

- Sort By Name
- Sort By Date
- Ascending
- Descending
- Thumbnails
- List
- Download All

mdev30651-test.diff
2 kB
2024-06-11 12:14

Issue Links

is duplicated by

MDEV-34444 [ERROR] mysqld got signal 11 ;

Closed

relates to

MDEV-22160 SIGSEGV in st_join_table::save_explain_data on SELECT

Closed

MDEV-19720 Server crash in st_join_table::save_explain_data or Assertion `sel->quick' failed in JOIN::make_range_rowid_filters with rowid_filter=on

Closed

MDEV-26446 Crash on st_join_table::save_explain_data

Closed

MDEV-33510 Server crash : mysqld got signal 11 in st_join_table::save_explain_data

Closed

Activity

Ascending order - Click to sort in descending order

Roel Van de Paar added a comment - 2023-02-14 09:08 - edited

MTR Testcase

SET storage_engine=MyISAM, sql_mode='';

CREATE TABLE t (c1 INT KEY,c2 INT,c3 TIME,INDEX (c2));

INSERT INTO t VALUES (0,0,0),(1000,0,0);

--error ER_UNKNOWN_STMT_HANDLER

EXECUTE x;

SET @@max_statement_time=0.0001;

--error ER_STATEMENT_TIMEOUT

SELECT * FROM t WHERE c1 >='00:00:00' AND c1 <'23:00:00' AND c2='13:13:13';

DROP TABLE t;

Run with --repeat and for example 100 or 300 executions.

Roel Van de Paar added a comment - 2023-02-14 09:08 - edited MTR Testcase SET storage_engine=MyISAM, sql_mode= '' ; CREATE TABLE t (c1 INT KEY ,c2 INT ,c3 TIME , INDEX (c2)); INSERT INTO t VALUES (0,0,0),(1000,0,0); --error ER_UNKNOWN_STMT_HANDLER EXECUTE x; SET @@max_statement_time=0.0001; --error ER_STATEMENT_TIMEOUT SELECT * FROM t WHERE c1 >= '00:00:00' AND c1 < '23:00:00' AND c2= '13:13:13' ; DROP TABLE t; Run with --repeat and for example 100 or 300 executions.

Roel Van de Paar added a comment - 2023-02-14 09:14

What is very interesting is that the optimized crashes have the same stack as the previously fixed ~~MDEV-22160~~, and the testcase looks related.

Roel Van de Paar added a comment - 2023-02-14 09:14 What is very interesting is that the optimized crashes have the same stack as the previously fixed MDEV-22160 , and the testcase looks related.

Alice Sherepa added a comment - 2023-07-10 12:32

not reproducible on 10.5 anymore (29bc61912e44996643), 11.0 313c5a1dfb (I tried with --repeat=1000)

Alice Sherepa added a comment - 2023-07-10 12:32 not reproducible on 10.5 anymore (29bc61912e44996643), 11.0 313c5a1dfb (I tried with --repeat=1000)

Roel Van de Paar added a comment - 2024-05-27 23:08 - edited

The bug seems less reproducible than before, but still is. This is on a 10.6 build from 17 May 24:

10.6.19 9a95f6b53b44a8be64817b92bb56423c6fad5a0d (Optimized)
Core was generated by `/test/MD170524-mariadb-10.6.19-linux-x86_64-opt/bin/mariadbd --no-defaults --ma'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00005629ebc8b8b6 in st_join_table::save_explain_data (this=this@entry=0x1494c80153f0, eta=eta@entry=0x1494c8084ea0, prefix_tables=prefix_tables@entry=0, distinct_arg=distinct_arg@entry=false, first_top_tab=first_top_tab@entry=0x1494c80153f0)at /test/10.6_opt/sql/sql_select.cc:28253
[Current thread is 1 (LWP 2800677)]
(gdb) bt
#0 0x00005629ebc8b8b6 in st_join_table::save_explain_data (this=this@entry=0x1494c80153f0, eta=eta@entry=0x1494c8084ea0, prefix_tables=prefix_tables@entry=0, distinct_arg=distinct_arg@entry=false, first_top_tab=first_top_tab@entry=0x1494c80153f0)at /test/10.6_opt/sql/sql_select.cc:28253
#1 0x00005629ebc8d56b in JOIN::save_explain_data_intern (this=this@entry=0x1494c8012de8, output=0x1494c8013390, need_tmp_table_arg=<optimized out>, need_order_arg=<optimized out>, distinct_arg=distinct_arg@entry=false, message=<optimized out>)at /test/10.6_opt/sql/sql_select.cc:28813
#2 0x00005629ebc8d83b in JOIN::save_explain_data (this=this@entry=0x1494c8012de8, output=0x1494c8013390, can_overwrite=can_overwrite@entry=false, need_tmp_table=<optimized out>, need_order=<optimized out>, distinct=<optimized out>)at /test/10.6_opt/sql/sql_select.cc:4645
#3 0x00005629ebc8d903 in JOIN::build_explain (this=this@entry=0x1494c8012de8)at /test/10.6_opt/sql/sql_select.cc:1854
#4 0x00005629ebc9962a in JOIN::optimize (this=this@entry=0x1494c8012de8)at /test/10.6_opt/sql/sql_select.cc:1914
#5 0x00005629ebc99717 in mysql_select (thd=thd@entry=0x1494c8000c68, tables=0x1494c80110d8, fields=@0x1494c8010d60: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x1494c8011088, last = 0x1494c80138c0, elements = 3}, <No data fields>}, conds=0x1494c8011fb0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x1494c8012dc0, unit=0x1494c8004e70, select_lex=0x1494c8010aa8)at /test/10.6_opt/sql/sql_select.cc:5151
#6 0x00005629ebc99f34 in handle_select (thd=thd@entry=0x1494c8000c68, lex=lex@entry=0x1494c8004da8, result=result@entry=0x1494c8012dc0, setup_tables_done_option=setup_tables_done_option@entry=0)at /test/10.6_opt/sql/sql_select.cc:559
#7 0x00005629ebc1c610 in execute_sqlcom_select (thd=thd@entry=0x1494c8000c68, all_tables=0x1494c80110d8) at /test/10.6_opt/sql/sql_parse.cc:6379
#8 0x00005629ebc2b4b6 in mysql_execute_command (thd=thd@entry=0x1494c8000c68, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false)at /test/10.6_opt/sql/sql_parse.cc:3987
#9 0x00005629ebc2cc8e in mysql_parse (thd=0x1494c8000c68, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at /test/10.6_opt/sql/sql_parse.cc:8146
#10 0x00005629ebc2f64d in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x1494c8000c68, packet=packet@entry=0x1494c8008619 "SELECT * FROM t WHERE c1 >='00:00:00' AND c1 <'23:00:00' AND c2='13:13:13';", packet_length=packet_length@entry=75, blocking=blocking@entry=true) at /test/10.6_opt/sql/sql_parse.cc:1995
#11 0x00005629ebc312ec in do_command (thd=0x1494c8000c68, blocking=blocking@entry=true) at /test/10.6_opt/sql/sql_parse.cc:1409
#12 0x00005629ebd4d287 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x5629ef78b0b8, put_in_cache=put_in_cache@entry=true)at /test/10.6_opt/sql/sql_connect.cc:1415
#13 0x00005629ebd4d5fd in handle_one_connection (arg=arg@entry=0x5629ef78b0b8)at /test/10.6_opt/sql/sql_connect.cc:1317
#14 0x00005629ec105003 in pfs_spawn_thread (arg=0x5629ef7b4b98)at /test/10.6_opt/storage/perfschema/pfs.cc:2201
#15 0x0000149518297ada in start_thread (arg=<optimized out>)at ./nptl/pthread_create.c:444
#16 0x000014951832847c in clone3 ()at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

In this case I used pquery replaying the testcase in the original description, with 5000 threads against a single server instance.
No special mysqld or optimizer options set.

Roel Van de Paar added a comment - 2024-05-27 23:08 - edited The bug seems less reproducible than before, but still is. This is on a 10.6 build from 17 May 24: 10.6.19 9a95f6b53b44a8be64817b92bb56423c6fad5a0d (Optimized) Core was generated by `/test/MD170524-mariadb-10.6.19-linux-x86_64-opt/bin/mariadbd --no-defaults --ma'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00005629ebc8b8b6 in st_join_table::save_explain_data (this=this@entry=0x1494c80153f0, eta=eta@entry=0x1494c8084ea0, prefix_tables=prefix_tables@entry=0, distinct_arg=distinct_arg@entry=false, first_top_tab=first_top_tab@entry=0x1494c80153f0)at /test/10.6_opt/sql/sql_select.cc:28253 [Current thread is 1 (LWP 2800677)] (gdb) bt #0 0x00005629ebc8b8b6 in st_join_table::save_explain_data (this=this@entry=0x1494c80153f0, eta=eta@entry=0x1494c8084ea0, prefix_tables=prefix_tables@entry=0, distinct_arg=distinct_arg@entry=false, first_top_tab=first_top_tab@entry=0x1494c80153f0)at /test/10.6_opt/sql/sql_select.cc:28253 #1 0x00005629ebc8d56b in JOIN::save_explain_data_intern (this=this@entry=0x1494c8012de8, output=0x1494c8013390, need_tmp_table_arg=<optimized out>, need_order_arg=<optimized out>, distinct_arg=distinct_arg@entry=false, message=<optimized out>)at /test/10.6_opt/sql/sql_select.cc:28813 #2 0x00005629ebc8d83b in JOIN::save_explain_data (this=this@entry=0x1494c8012de8, output=0x1494c8013390, can_overwrite=can_overwrite@entry=false, need_tmp_table=<optimized out>, need_order=<optimized out>, distinct=<optimized out>)at /test/10.6_opt/sql/sql_select.cc:4645 #3 0x00005629ebc8d903 in JOIN::build_explain (this=this@entry=0x1494c8012de8)at /test/10.6_opt/sql/sql_select.cc:1854 #4 0x00005629ebc9962a in JOIN::optimize (this=this@entry=0x1494c8012de8)at /test/10.6_opt/sql/sql_select.cc:1914 #5 0x00005629ebc99717 in mysql_select (thd=thd@entry=0x1494c8000c68, tables=0x1494c80110d8, fields=@0x1494c8010d60: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x1494c8011088, last = 0x1494c80138c0, elements = 3}, <No data fields>}, conds=0x1494c8011fb0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x1494c8012dc0, unit=0x1494c8004e70, select_lex=0x1494c8010aa8)at /test/10.6_opt/sql/sql_select.cc:5151 #6 0x00005629ebc99f34 in handle_select (thd=thd@entry=0x1494c8000c68, lex=lex@entry=0x1494c8004da8, result=result@entry=0x1494c8012dc0, setup_tables_done_option=setup_tables_done_option@entry=0)at /test/10.6_opt/sql/sql_select.cc:559 #7 0x00005629ebc1c610 in execute_sqlcom_select (thd=thd@entry=0x1494c8000c68, all_tables=0x1494c80110d8) at /test/10.6_opt/sql/sql_parse.cc:6379 #8 0x00005629ebc2b4b6 in mysql_execute_command (thd=thd@entry=0x1494c8000c68, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false)at /test/10.6_opt/sql/sql_parse.cc:3987 #9 0x00005629ebc2cc8e in mysql_parse (thd=0x1494c8000c68, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at /test/10.6_opt/sql/sql_parse.cc:8146 #10 0x00005629ebc2f64d in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x1494c8000c68, packet=packet@entry=0x1494c8008619 "SELECT * FROM t WHERE c1 >='00:00:00' AND c1 <'23:00:00' AND c2='13:13:13';", packet_length=packet_length@entry=75, blocking=blocking@entry=true) at /test/10.6_opt/sql/sql_parse.cc:1995 #11 0x00005629ebc312ec in do_command (thd=0x1494c8000c68, blocking=blocking@entry=true) at /test/10.6_opt/sql/sql_parse.cc:1409 #12 0x00005629ebd4d287 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x5629ef78b0b8, put_in_cache=put_in_cache@entry=true)at /test/10.6_opt/sql/sql_connect.cc:1415 #13 0x00005629ebd4d5fd in handle_one_connection (arg=arg@entry=0x5629ef78b0b8)at /test/10.6_opt/sql/sql_connect.cc:1317 #14 0x00005629ec105003 in pfs_spawn_thread (arg=0x5629ef7b4b98)at /test/10.6_opt/storage/perfschema/pfs.cc:2201 #15 0x0000149518297ada in start_thread (arg=<optimized out>)at ./nptl/pthread_create.c:444 #16 0x000014951832847c in clone3 ()at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 In this case I used pquery replaying the testcase in the original description, with 5000 threads against a single server instance. No special mysqld or optimizer options set.

Roel Van de Paar added a comment - 2024-05-27 23:14

Also reproduced in 10.5.26 4911ec1a5bc07ef20c9018386a3a2671c59c4dca (Optimized) from 17 May 24 in the same way

Roel Van de Paar added a comment - 2024-05-27 23:14 Also reproduced in 10.5.26 4911ec1a5bc07ef20c9018386a3a2671c59c4dca (Optimized) from 17 May 24 in the same way

Roel Van de Paar added a comment - 2024-05-27 23:42 - edited

Optimized builds readily reproduce the SIGSEGV (in ~500 attempts using --repeat), including with the MTR test case above with the following change:

# The "ER_STATEMENT_TIMEOUT/1969: Query execution was interrupted (max_statement_time exceeded)" output is only hit occasionally

--error 0,ER_STATEMENT_TIMEOUT

As a sidenote, and interestingly, there is no error output when this MTR construct is used, i.e. even though ER_STATEMENT_TIMEOUT is hit with some regularity, it is not shown.

Roel Van de Paar added a comment - 2024-05-27 23:42 - edited Optimized builds readily reproduce the SIGSEGV (in ~500 attempts using --repeat), including with the MTR test case above with the following change: # The "ER_STATEMENT_TIMEOUT/1969: Query execution was interrupted (max_statement_time exceeded)" output is only hit occasionally --error 0,ER_STATEMENT_TIMEOUT As a sidenote, and interestingly, there is no error output when this MTR construct is used, i.e. even though ER_STATEMENT_TIMEOUT is hit with some regularity, it is not shown.

Roel Van de Paar added a comment - 2024-05-27 23:47 - edited

Given the repeatable MTR testcase for optimized build (with --repeat) it should also be easy to obtain an rr trace if so desired (directly from MTR).

Roel Van de Paar added a comment - 2024-05-27 23:47 - edited Given the repeatable MTR testcase for optimized build (with --repeat) it should also be easy to obtain an rr trace if so desired (directly from MTR).

Roel Van de Paar added a comment - 2024-05-28 00:13 - edited

The sel->quick assertion on debug is harder to reproduce, but still exists as well:

10.6.19 9a95f6b53b44a8be64817b92bb56423c6fad5a0d (Debug)
mariadbd: /test/10.6_dbg/sql/sql_select.cc:2002: bool JOIN::make_range_rowid_filters(): Assertion `sel->quick' failed.

10.6.19 9a95f6b53b44a8be64817b92bb56423c6fad5a0d (Debug)
Core was generated by `/test/MD170524-mariadb-10.6.19-linux-x86_64-dbg/bin/mariadbd --no-defaults --ma'.
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>)at ./nptl/pthread_kill.c:44
Download failed: Invalid argument. Continuing without source file ./nptl/./nptl/pthread_kill.c.
[Current thread is 1 (LWP 1163196)]
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>)at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=<optimized out>)at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6)at ./nptl/pthread_kill.c:89
#3 0x00001484cbe42866 in __GI_raise (sig=sig@entry=6)at ../sysdeps/posix/raise.c:26
#4 0x00001484cbe268b7 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00001484cbe267db in __assert_fail_base (fmt=0x1484cbfc5168 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55f4c7dea008 "sel->quick", file=file@entry=0x55f4c7c3a3c0 "/test/10.6_dbg/sql/sql_select.cc", line=line@entry=2002, function=function@entry=0x55f4c7c3b0a0 "bool JOIN::make_range_rowid_filters()") at ./assert/assert.c:92
#6 0x00001484cbe39186 in __assert_fail (assertion=0x55f4c7dea008 "sel->quick", file=0x55f4c7c3a3c0 "/test/10.6_dbg/sql/sql_select.cc", line=2002, function=0x55f4c7c3b0a0 "bool JOIN::make_range_rowid_filters()")at ./assert/assert.c:101
#7 0x000055f4c6fa8c8c in JOIN::make_range_rowid_filters (this=this@entry=0x1484800158c8) at /test/10.6_dbg/sql/sql_select.cc:2002
#8 0x000055f4c6fdd4ae in JOIN::optimize_stage2 (this=this@entry=0x1484800158c8) at /test/10.6_dbg/sql/sql_select.cc:2638
#9 0x000055f4c6fe1169 in JOIN::optimize_inner (this=this@entry=0x1484800158c8)at /test/10.6_dbg/sql/sql_select.cc:2614
#10 0x000055f4c6fe164c in JOIN::optimize (this=this@entry=0x1484800158c8)at /test/10.6_dbg/sql/sql_select.cc:1908
#11 0x000055f4c6fe1725 in mysql_select (thd=thd@entry=0x148480000d58, tables=0x148480013bb8, fields=@0x148480013840: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x148480013b68, last = 0x1484800163a8, elements = 3}, <No data fields>}, conds=0x148480014a90, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x1484800158a0, unit=0x148480005128, select_lex=0x148480013588)at /test/10.6_dbg/sql/sql_select.cc:5151
#12 0x000055f4c6fe1f71 in handle_select (thd=thd@entry=0x148480000d58, lex=lex@entry=0x148480005060, result=result@entry=0x1484800158a0, setup_tables_done_option=setup_tables_done_option@entry=0)at /test/10.6_dbg/sql/sql_select.cc:559
#13 0x000055f4c6f59445 in execute_sqlcom_select (thd=thd@entry=0x148480000d58, all_tables=0x148480013bb8) at /test/10.6_dbg/sql/sql_parse.cc:6379
#14 0x000055f4c6f64e69 in mysql_execute_command (thd=thd@entry=0x148480000d58, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false)at /test/10.6_dbg/sql/sql_parse.cc:3987
#15 0x000055f4c6f6c33f in mysql_parse (thd=thd@entry=0x148480000d58, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x1484c09af2c0)at /test/10.6_dbg/sql/sql_parse.cc:8146
#16 0x000055f4c6f6e80f in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x148480000d58, packet=packet@entry=0x14848000b0a9 "SELECT * FROM t WHERE c1 >='00:00:00' AND c1 <'23:00:00' AND c2='13:13:13';", packet_length=packet_length@entry=75, blocking=blocking@entry=true) at /test/10.6_dbg/sql/sql_class.h:240
#17 0x000055f4c6f70aa6 in do_command (thd=0x148480000d58, blocking=blocking@entry=true) at /test/10.6_dbg/sql/sql_parse.cc:1409
#18 0x000055f4c70bd9e2 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55f4c9901d48, put_in_cache=put_in_cache@entry=true)at /test/10.6_dbg/sql/sql_connect.cc:1415
#19 0x000055f4c70bdce2 in handle_one_connection (arg=arg@entry=0x55f4c9901d48)at /test/10.6_dbg/sql/sql_connect.cc:1317
#20 0x000055f4c7509aa2 in pfs_spawn_thread (arg=0x55f4c986e3d8)at /test/10.6_dbg/storage/perfschema/pfs.cc:2201
#21 0x00001484cbe97ada in start_thread (arg=<optimized out>)at ./nptl/pthread_create.c:444
#22 0x00001484cbf2847c in clone3 ()at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

In this case I also used pquery replaying the testcase in the original description, with 5k threads against a single server instance, random replay order.

Roel Van de Paar added a comment - 2024-05-28 00:13 - edited The sel->quick assertion on debug is harder to reproduce, but still exists as well: 10.6.19 9a95f6b53b44a8be64817b92bb56423c6fad5a0d (Debug) mariadbd: /test/10.6_dbg/sql/sql_select.cc:2002: bool JOIN::make_range_rowid_filters(): Assertion `sel->quick' failed. 10.6.19 9a95f6b53b44a8be64817b92bb56423c6fad5a0d (Debug) Core was generated by `/test/MD170524-mariadb-10.6.19-linux-x86_64-dbg/bin/mariadbd --no-defaults --ma'. Program terminated with signal SIGABRT, Aborted. #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>)at ./nptl/pthread_kill.c:44 Download failed: Invalid argument. Continuing without source file ./nptl/./nptl/pthread_kill.c. [Current thread is 1 (LWP 1163196)] (gdb) bt #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>)at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=6, threadid=<optimized out>)at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6)at ./nptl/pthread_kill.c:89 #3 0x00001484cbe42866 in __GI_raise (sig=sig@entry=6)at ../sysdeps/posix/raise.c:26 #4 0x00001484cbe268b7 in __GI_abort () at ./stdlib/abort.c:79 #5 0x00001484cbe267db in __assert_fail_base (fmt=0x1484cbfc5168 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55f4c7dea008 "sel->quick", file=file@entry=0x55f4c7c3a3c0 "/test/10.6_dbg/sql/sql_select.cc", line=line@entry=2002, function=function@entry=0x55f4c7c3b0a0 "bool JOIN::make_range_rowid_filters()") at ./assert/assert.c:92 #6 0x00001484cbe39186 in __assert_fail (assertion=0x55f4c7dea008 "sel->quick", file=0x55f4c7c3a3c0 "/test/10.6_dbg/sql/sql_select.cc", line=2002, function=0x55f4c7c3b0a0 "bool JOIN::make_range_rowid_filters()")at ./assert/assert.c:101 #7 0x000055f4c6fa8c8c in JOIN::make_range_rowid_filters (this=this@entry=0x1484800158c8) at /test/10.6_dbg/sql/sql_select.cc:2002 #8 0x000055f4c6fdd4ae in JOIN::optimize_stage2 (this=this@entry=0x1484800158c8) at /test/10.6_dbg/sql/sql_select.cc:2638 #9 0x000055f4c6fe1169 in JOIN::optimize_inner (this=this@entry=0x1484800158c8)at /test/10.6_dbg/sql/sql_select.cc:2614 #10 0x000055f4c6fe164c in JOIN::optimize (this=this@entry=0x1484800158c8)at /test/10.6_dbg/sql/sql_select.cc:1908 #11 0x000055f4c6fe1725 in mysql_select (thd=thd@entry=0x148480000d58, tables=0x148480013bb8, fields=@0x148480013840: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x148480013b68, last = 0x1484800163a8, elements = 3}, <No data fields>}, conds=0x148480014a90, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x1484800158a0, unit=0x148480005128, select_lex=0x148480013588)at /test/10.6_dbg/sql/sql_select.cc:5151 #12 0x000055f4c6fe1f71 in handle_select (thd=thd@entry=0x148480000d58, lex=lex@entry=0x148480005060, result=result@entry=0x1484800158a0, setup_tables_done_option=setup_tables_done_option@entry=0)at /test/10.6_dbg/sql/sql_select.cc:559 #13 0x000055f4c6f59445 in execute_sqlcom_select (thd=thd@entry=0x148480000d58, all_tables=0x148480013bb8) at /test/10.6_dbg/sql/sql_parse.cc:6379 #14 0x000055f4c6f64e69 in mysql_execute_command (thd=thd@entry=0x148480000d58, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false)at /test/10.6_dbg/sql/sql_parse.cc:3987 #15 0x000055f4c6f6c33f in mysql_parse (thd=thd@entry=0x148480000d58, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x1484c09af2c0)at /test/10.6_dbg/sql/sql_parse.cc:8146 #16 0x000055f4c6f6e80f in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x148480000d58, packet=packet@entry=0x14848000b0a9 "SELECT * FROM t WHERE c1 >='00:00:00' AND c1 <'23:00:00' AND c2='13:13:13';", packet_length=packet_length@entry=75, blocking=blocking@entry=true) at /test/10.6_dbg/sql/sql_class.h:240 #17 0x000055f4c6f70aa6 in do_command (thd=0x148480000d58, blocking=blocking@entry=true) at /test/10.6_dbg/sql/sql_parse.cc:1409 #18 0x000055f4c70bd9e2 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55f4c9901d48, put_in_cache=put_in_cache@entry=true)at /test/10.6_dbg/sql/sql_connect.cc:1415 #19 0x000055f4c70bdce2 in handle_one_connection (arg=arg@entry=0x55f4c9901d48)at /test/10.6_dbg/sql/sql_connect.cc:1317 #20 0x000055f4c7509aa2 in pfs_spawn_thread (arg=0x55f4c986e3d8)at /test/10.6_dbg/storage/perfschema/pfs.cc:2201 #21 0x00001484cbe97ada in start_thread (arg=<optimized out>)at ./nptl/pthread_create.c:444 #22 0x00001484cbf2847c in clone3 ()at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 In this case I also used pquery replaying the testcase in the original description, with 5k threads against a single server instance, random replay order.

Roel Van de Paar added a comment - 2024-05-28 01:05 - edited

Seemingly not repeatable on 11.5 (dbg nor opt)

Roel Van de Paar added a comment - 2024-05-28 01:05 - edited Seemingly not repeatable on 11.5 (dbg nor opt)

Roel Van de Paar added a comment - 2024-06-10 23:45 - edited

While all info is in above comments, thought I would add best way to reproduce here also:

./mtr --repeat 5000 --parallel 20 test{,,,,,,,,,,,,,,,,,,,,}

With main/test.test being:

SET storage_engine=MyISAM, sql_mode='';

CREATE TABLE t (c1 INT KEY,c2 INT,c3 TIME,INDEX (c2));

INSERT INTO t VALUES (0,0,0),(1000,0,0);

SET @@max_statement_time=0.0001;

# The "ER_STATEMENT_TIMEOUT/1969: Query execution was interrupted (max_statement_time exceeded)" output is only hit occasionally

--error 0,ER_STATEMENT_TIMEOUT

SELECT * FROM t WHERE c1 >='00:00:00' AND c1 <'23:00:00' AND c2='13:13:13';

DROP TABLE t;

Reproduces the SIGSEGV in 10-30 seconds on an 10.6 optimized/release build from 17 May (9a95f6b53b44a8be64817b92bb56423c6fad5a0d).
I was also able to eliminate the EXECUTE statement and the issue still reproduces.
The issue furthermore seems to be MyISAM only; the bug does not reproduce when using InnoDB.

Roel Van de Paar added a comment - 2024-06-10 23:45 - edited While all info is in above comments, thought I would add best way to reproduce here also: . /mtr --repeat 5000 --parallel 20 test {,,,,,,,,,,,,,,,,,,,,} With main/test.test being: SET storage_engine=MyISAM, sql_mode= '' ; CREATE TABLE t (c1 INT KEY ,c2 INT ,c3 TIME , INDEX (c2)); INSERT INTO t VALUES (0,0,0),(1000,0,0); SET @@max_statement_time=0.0001; # The "ER_STATEMENT_TIMEOUT/1969: Query execution was interrupted (max_statement_time exceeded)" output is only hit occasionally --error 0,ER_STATEMENT_TIMEOUT SELECT * FROM t WHERE c1 >= '00:00:00' AND c1 < '23:00:00' AND c2= '13:13:13' ; DROP TABLE t; Reproduces the SIGSEGV in 10-30 seconds on an 10.6 optimized/release build from 17 May (9a95f6b53b44a8be64817b92bb56423c6fad5a0d). I was also able to eliminate the EXECUTE statement and the issue still reproduces. The issue furthermore seems to be MyISAM only; the bug does not reproduce when using InnoDB.

Roel Van de Paar added a comment - 2024-06-11 00:13 - edited

Re-confirmed in 10.11 also, and confirmed not reproducible in >= 11.1

Roel Van de Paar added a comment - 2024-06-11 00:13 - edited Re-confirmed in 10.11 also, and confirmed not reproducible in >= 11.1

Sergei Petrunia added a comment - 2024-06-11 12:14

A testcase with DEBUG_SYNC: mdev30651-test.diff

Sergei Petrunia added a comment - 2024-06-11 12:14 A testcase with DEBUG_SYNC: mdev30651-test.diff

Sergei Petrunia added a comment - 2024-06-11 13:18

Variant for 10.5:

commit 00844bd1677b37baa981d1e81f991abb3b52041e (HEAD -> bb-10.5-MDEV-30651, origin/bb-10.5-MDEV-30651)

Author: Sergei Petrunia <sergey@mariadb.com>

Date:   Tue Jun 11 16:16:11 2024 +0300

    MDEV-30651: Assertion `sel->quick' in make_range_rowid_filters

Sergei Petrunia added a comment - 2024-06-11 13:18 Variant for 10.5: commit 00844bd1677b37baa981d1e81f991abb3b52041e (HEAD -> bb-10.5-MDEV-30651, origin/bb-10.5-MDEV-30651) Author: Sergei Petrunia <sergey@mariadb.com> Date: Tue Jun 11 16:16:11 2024 +0300 MDEV-30651: Assertion `sel->quick' in make_range_rowid_filters

Sergei Petrunia added a comment - 2024-06-11 13:21

Variant for 10.6+:

commit 227a821e06742ea9ab85a1e511fb28ba174b1d88 (HEAD -> bb-10.6-MDEV-30651, origin/bb-10.6-MDEV-30651, 10.6)

Author: Sergei Petrunia <sergey@mariadb.com>

Date:   Tue Jun 11 16:20:00 2024 +0300

    MDEV-30651: Assertion `sel->quick' in make_range_rowid_filters

    (Variant for 10.6: return error code from SQL_SELECT::test_quick_select)

    The optimizer deals with Rowid Filters this way:

Sergei Petrunia added a comment - 2024-06-11 13:21 Variant for 10.6+: commit 227a821e06742ea9ab85a1e511fb28ba174b1d88 (HEAD -> bb-10.6-MDEV-30651, origin/bb-10.6-MDEV-30651, 10.6) Author: Sergei Petrunia <sergey@mariadb.com> Date: Tue Jun 11 16:20:00 2024 +0300 MDEV-30651: Assertion `sel->quick' in make_range_rowid_filters (Variant for 10.6: return error code from SQL_SELECT::test_quick_select) The optimizer deals with Rowid Filters this way:

Michael Widenius added a comment - 2024-06-13 14:49

Ok. (With an unrelated comment about improving statement_should_be_aborted()

Michael Widenius added a comment - 2024-06-13 14:49 Ok. (With an unrelated comment about improving statement_should_be_aborted()

Sergei Petrunia added a comment - 2024-06-14 12:46 - edited

Looking at code in bool JOIN::make_range_rowid_filters() , I see one more issue:

  no_filter:

    if (sel->quick)

      delete sel->quick;

    delete sel;

Suppose this is executed with sel->quick!=NULL. It will delete the sel->quick, but leave the pointer.
Then, it will delete sel which will go into:

SQL_SELECT::~SQL_SELECT()

  cleanup();

and into

void SQL_SELECT::cleanup()

  delete quick;

which will double-delete the same object.

Interestingly, this doesn't seem to affect the mtr... is it because we had quick=NULL ?

The code in question was added by the fix for MDEV-19856.
Its test coverage was (accidentally?) removed in this patch:

commit 58cd0bd59ef011be54f162237f2ff017c3148e7b

Author: Igor Babaev <igor@askmonty.org>

Date:   Mon Oct 17 16:44:10 2022 -0700

    MDEV-28846 Poor performance when rowid filter contains no elements

... but even if I modify the testcase and put the coverage back, there's still no crash or anything.

Sergei Petrunia added a comment - 2024-06-14 12:46 - edited Looking at code in bool JOIN::make_range_rowid_filters() , I see one more issue: no_filter: if (sel->quick) delete sel->quick; delete sel; Suppose this is executed with sel->quick!=NULL. It will delete the sel->quick , but leave the pointer. Then, it will delete sel which will go into: SQL_SELECT::~SQL_SELECT() { cleanup(); and into void SQL_SELECT::cleanup() { delete quick; which will double-delete the same object. Interestingly, this doesn't seem to affect the mtr... is it because we had quick=NULL ? The code in question was added by the fix for MDEV-19856 . Its test coverage was (accidentally?) removed in this patch: commit 58cd0bd59ef011be54f162237f2ff017c3148e7b Author: Igor Babaev <igor@askmonty.org> Date: Mon Oct 17 16:44:10 2022 -0700 MDEV-28846 Poor performance when rowid filter contains no elements ... but even if I modify the testcase and put the coverage back, there's still no crash or anything.

Sergei Petrunia added a comment - 2024-06-14 12:49 - edited

... another thing that doesn't look nice is that

bool JOIN::make_range_rowid_filters()

always return false (even in unrecoverable errors), despite its caller checking its return value:

  if (make_range_rowid_filters())

    DBUG_RETURN(1);

(EDIT: but it has already been changed in 10.6)

Sergei Petrunia added a comment - 2024-06-14 12:49 - edited ... another thing that doesn't look nice is that bool JOIN ::make_range_rowid_filters() always return false (even in unrecoverable errors), despite its caller checking its return value: if (make_range_rowid_filters()) DBUG_RETURN(1); (EDIT: but it has already been changed in 10.6)

Sergei Petrunia added a comment - 2024-06-17 11:01

A side observation:
the function statement_should_be_aborted() is badly named, because it returns true also when we've reached MAX_SEL_ARGS limit. But reaching this limit does NOT mean that "statement should be aborted"! Only range analysis should be.

This was introduced in:

commit b77252819719400166ce8541ee0bd5fa389f4a12

Author: Tor Didriksen <tor.didriksen@oracle.com>

Date:   Tue Mar 19 17:09:17 2013 +0100

    Bug#13009341 CRASH IN STR_TO_DATETIME AFTER MISBEHAVING "BLOB" VALUE COMPARISON

    The range optimizer uses 'save_in_field_no_warnings()' to verify properties of

    'value <cmp> field' expressions.

    If this execution yields an error, it should abort.

then got into MariaDB. In MySQL, this function is already gone.

Sergei Petrunia added a comment - 2024-06-17 11:01 A side observation: the function statement_should_be_aborted() is badly named, because it returns true also when we've reached MAX_SEL_ARGS limit. But reaching this limit does NOT mean that "statement should be aborted"! Only range analysis should be. This was introduced in: commit b77252819719400166ce8541ee0bd5fa389f4a12 Author: Tor Didriksen <tor.didriksen@oracle.com> Date: Tue Mar 19 17:09:17 2013 +0100 Bug#13009341 CRASH IN STR_TO_DATETIME AFTER MISBEHAVING "BLOB" VALUE COMPARISON The range optimizer uses 'save_in_field_no_warnings()' to verify properties of 'value <cmp> field' expressions. If this execution yields an error, it should abort. then got into MariaDB. In MySQL, this function is already gone.

Sergei Petrunia added a comment - 2024-06-17 11:56

Pushed into 10.5:

2eda310b155 (HEAD -> 10.5, origin/bb-10.5-MDEV-30651, origin/10.5, bb-10.5-MDEV-30651) Restore test coverage for MDEV-18956

0903276eaea MDEV-30651: Assertion `sel->quick' in make_range_rowid_filters, followup

a2066b2400f MDEV-30651: Assertion `sel->quick' in make_range_rowid_filters

and into 10.6:

commit ef9e3e73ed52e55842e6ba40dfa94a78fb06cbee (origin/bb-10.6-MDEV-30651, origin/HEAD, origin/10.6)

Author: Sergei Petrunia <sergey@mariadb.com>

Date:   Tue Jun 11 16:20:00 2024 +0300

    MDEV-30651: Assertion `sel->quick' in make_range_rowid_filters

    (Variant for 10.6: return error code from SQL_SELECT::test_quick_select)

Sergei Petrunia added a comment - 2024-06-17 11:56 Pushed into 10.5: 2eda310b155 (HEAD -> 10.5, origin/bb-10.5-MDEV-30651, origin/10.5, bb-10.5-MDEV-30651) Restore test coverage for MDEV-18956 0903276eaea MDEV-30651: Assertion `sel->quick' in make_range_rowid_filters, followup a2066b2400f MDEV-30651: Assertion `sel->quick' in make_range_rowid_filters and into 10.6: commit ef9e3e73ed52e55842e6ba40dfa94a78fb06cbee (origin/bb-10.6-MDEV-30651, origin/HEAD, origin/10.6) Author: Sergei Petrunia <sergey@mariadb.com> Date: Tue Jun 11 16:20:00 2024 +0300 MDEV-30651: Assertion `sel->quick' in make_range_rowid_filters (Variant for 10.6: return error code from SQL_SELECT::test_quick_select)

Igor Babaev (Inactive) added a comment - 2024-06-28 02:58

The following simple variant of the original test case could demonstrate the same problem:

CREATE TABLE t (c1 INT PRIMARY KEY,c2 INT, c3 INT ,INDEX (c2)) ENGINE=MYISAM;

INSERT INTO t VALUES (0,0,0),(1000,0,0);

EXPLAIN SELECT * FROM t WHERE c1 >= 0 AND c1 < 10 AND c2=13;

--disable_query_log

SET @@max_statement_time=0.00001;

--disable_result_log

--error 0,ER_STATEMENT_TIMEOUT

EXPLAIN SELECT * FROM t WHERE c1 >= 0 AND c1 < 10 AND c2=13;

--enable_result_log

--enable_query_log

DROP TABLE t;

The test should be run as a separate mtr test repeatedly by the following command:

../mtr --force --max-test-fail=1000 --repeat=1000 --parallel 8 main.rowid_filter_kill{,,,,,,,}

Usually the crash happens in less than 200 iterations.

Igor Babaev (Inactive) added a comment - 2024-06-28 02:58 The following simple variant of the original test case could demonstrate the same problem: CREATE TABLE t (c1 INT PRIMARY KEY ,c2 INT , c3 INT , INDEX (c2)) ENGINE=MYISAM; INSERT INTO t VALUES (0,0,0),(1000,0,0); EXPLAIN SELECT * FROM t WHERE c1 >= 0 AND c1 < 10 AND c2=13; --disable_query_log SET @@max_statement_time=0.00001; --disable_result_log --error 0,ER_STATEMENT_TIMEOUT EXPLAIN SELECT * FROM t WHERE c1 >= 0 AND c1 < 10 AND c2=13; --enable_result_log --enable_query_log DROP TABLE t; The test should be run as a separate mtr test repeatedly by the following command: ../mtr --force --max-test-fail=1000 --repeat=1000 --parallel 8 main.rowid_filter_kill{,,,,,,,} Usually the crash happens in less than 200 iterations.

Igor Babaev (Inactive) added a comment - 2024-06-28 04:12

psergei, monty: A possible problem that I see here for the patch pushed into 10.5 is that the 'killed' signal is not caught after the calls of SQL_SELECT::test_quick_select() within the code code of make_join_select(). Can it cause similar crashes when printing info for EXPLAIN?

Igor Babaev (Inactive) added a comment - 2024-06-28 04:12 psergei , monty : A possible problem that I see here for the patch pushed into 10.5 is that the 'killed' signal is not caught after the calls of SQL_SELECT::test_quick_select() within the code code of make_join_select(). Can it cause similar crashes when printing info for EXPLAIN?

Sergei Petrunia added a comment - 2024-07-10 07:26

igor no, it cannot. The code in make_join_select() does not have the property that "This call MUST produce a quick select, otherwise we end up in a logically incoherent state".

Sergei Petrunia added a comment - 2024-07-10 07:26 igor no, it cannot. The code in make_join_select() does not have the property that "This call MUST produce a quick select, otherwise we end up in a logically incoherent state".

Sergei Petrunia added a comment - 2024-08-15 09:31

Notes for the changelog:
A query that plans to use the Rowid Filter optimization could crash the server if some factor causes it to terminate abnormally at a certain specific point in query optimization. Examples of such causes of termination are: query being killed with KILL statement, statement execution exceeding @@max_statement_time limit.

Sergei Petrunia added a comment - 2024-08-15 09:31 Notes for the changelog: A query that plans to use the Rowid Filter optimization could crash the server if some factor causes it to terminate abnormally at a certain specific point in query optimization. Examples of such causes of termination are: query being killed with KILL statement, statement execution exceeding @@max_statement_time limit.

People

Assignee:: Sergei Petrunia

Reporter:: Roel Van de Paar

Votes:: 1 Vote for this issue

Watchers:: 10 Start watching this issue

Dates

Created:: 2023-02-14 09:07

Updated:: 2024-09-18 15:02

Resolved:: 2024-06-17 11:57

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Attachments

Issue Links

Activity

People

Dates

Git Integration