[MDEV-31403] Server crashes in st_join_table::choose_best_splitting (still) Created: 2023-06-05  Updated: 2024-01-25  Resolved: 2023-06-06

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.4, 10.5, 10.6, 10.8, 10.9, 10.10, 10.11
Fix Version/s: 10.4.30, 10.5.21, 10.6.14, 10.9.7, 10.10.5, 10.11.4

Type: Bug Priority: Blocker
Reporter: Elena Stepanova Assignee: Sergei Petrunia
Resolution: Fixed Votes: 0
Labels: regression

Issue Links:
Duplicate
is duplicated by MDEV-31436 MariaDB 10.6.13 segfaults on Moodle q... Closed
is duplicated by MDEV-31622 Crash on a specific query Closed
Relates
relates to MDEV-31241 Crashes in subselects in choose_best_... Closed
relates to MDEV-32064 Crash when searching for the best spl... Closed
relates to MDEV-31818 Server crashes in choose_best_splitting Open

 Description   

--source include/have_innodb.inc
 
CREATE TABLE t1 (a INT) ENGINE=InnoDB;
INSERT INTO t1 VALUES
  (1),(2),(3),(4),(5),(6),(7),(8),(9),(10),(11),(12),(13),(14),(15);
 
CREATE TABLE t2 (b INT) ENGINE=InnoDB;
INSERT INTO t2 VALUES (100),(200);
 
CREATE TABLE t3 (c INT, d INT, KEY(c)) ENGINE=InnoDB;
INSERT INTO t3 VALUES (1,1),(2,2);
 
CREATE VIEW v AS SELECT c, d FROM t3 GROUP BY c, d;
 
SELECT * FROM t1 JOIN t2 WHERE (t1.a, t2.b) IN (SELECT * FROM v);
 
# Cleanup
DROP VIEW v;
DROP TABLE t1, t2, t3;

bb-10.6-release fbe68a6a745

#3  <signal handler called>
#4  st_join_table::choose_best_splitting (this=0x7f3c2407c160, idx=2, remaining_tables=4, spl_pd_boundary=0x7f3c7c2f5d40) at /data/src/bb-10.6-release/sql/opt_split.cc:1048
#5  0x000055b653619ba2 in best_access_path (join=0x7f3c24075e88, s=0x7f3c2407c160, remaining_tables=4, join_positions=0x7f3c2407cca8, idx=2, disable_jbuf=true, record_count=30, pos=0x7f3c2407cf38, loose_scan_pos=0x7f3c7c2f6180) at /data/src/bb-10.6-release/sql/sql_select.cc:7898
#6  0x000055b6537f56f8 in fix_semijoin_strategies_for_picked_join_order (join=0x7f3c24075e88) at /data/src/bb-10.6-release/sql/opt_subselect.cc:3994
#7  0x000055b653622f3d in JOIN::get_best_combination (this=0x7f3c24075e88) at /data/src/bb-10.6-release/sql/sql_select.cc:11183
#8  0x000055b653607cc8 in JOIN::optimize_stage2 (this=0x7f3c24075e88) at /data/src/bb-10.6-release/sql/sql_select.cc:2556
#9  0x000055b653607b24 in JOIN::optimize_inner (this=0x7f3c24075e88) at /data/src/bb-10.6-release/sql/sql_select.cc:2535
#10 0x000055b653605244 in JOIN::optimize (this=0x7f3c24075e88) at /data/src/bb-10.6-release/sql/sql_select.cc:1848
#11 0x000055b653611145 in mysql_select (thd=0x7f3c24000dc8, tables=0x7f3c24015d58, fields=..., conds=0x7f3c24018c10, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f3c24075e60, unit=0x7f3c24005138, select_lex=0x7f3c24015740) at /data/src/bb-10.6-release/sql/sql_select.cc:5055
#12 0x000055b6535ff9fd in handle_select (thd=0x7f3c24000dc8, lex=0x7f3c24005070, result=0x7f3c24075e60, setup_tables_done_option=0) at /data/src/bb-10.6-release/sql/sql_select.cc:559
#13 0x000055b6535bdab1 in execute_sqlcom_select (thd=0x7f3c24000dc8, all_tables=0x7f3c24015d58) at /data/src/bb-10.6-release/sql/sql_parse.cc:6273
#14 0x000055b6535b49e5 in mysql_execute_command (thd=0x7f3c24000dc8, is_called_from_prepared_stmt=false) at /data/src/bb-10.6-release/sql/sql_parse.cc:3949
#15 0x000055b6535c2a8a in mysql_parse (thd=0x7f3c24000dc8, rawbuf=0x7f3c24015660 "SELECT * FROM t1 JOIN t2 WHERE (t1.a, t2.b) IN (SELECT * FROM v)", length=64, parser_state=0x7f3c7c2f7380) at /data/src/bb-10.6-release/sql/sql_parse.cc:8036
#16 0x000055b6535ae56b in dispatch_command (command=COM_QUERY, thd=0x7f3c24000dc8, packet=0x7f3c2400b8f9 "SELECT * FROM t1 JOIN t2 WHERE (t1.a, t2.b) IN (SELECT * FROM v)", packet_length=64, blocking=true) at /data/src/bb-10.6-release/sql/sql_parse.cc:1896
#17 0x000055b6535acec4 in do_command (thd=0x7f3c24000dc8, blocking=true) at /data/src/bb-10.6-release/sql/sql_parse.cc:1409
#18 0x000055b65377eeba in do_handle_one_connection (connect=0x55b6567779d8, put_in_cache=true) at /data/src/bb-10.6-release/sql/sql_connect.cc:1416
#19 0x000055b65377ec2f in handle_one_connection (arg=0x55b656777618) at /data/src/bb-10.6-release/sql/sql_connect.cc:1318
#20 0x000055b653cd7572 in pfs_spawn_thread (arg=0x55b6566c7d58) at /data/src/bb-10.6-release/storage/perfschema/pfs.cc:2201
#21 0x00007f3c82ea7fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#22 0x00007f3c82f285bc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

The fix for MDEV-31240 is in the branches.

The failure started happening after this commit in 10.4.29:

commit ce7ffe61d836fe9f0cfc1087f058bc40d66e5cfb
Author: Igor Babaev
Date:   Tue May 2 23:17:07 2023 -0700
 
    MDEV-26301 Split optimization refills temporary table too many times



 Comments   
Comment by Sergei Petrunia [ 2023-06-05 ]

The key part is here:

#4  st_join_table::choose_best_splitting (this=0x7f3c2407c160, idx=2, remaining_tables=4, spl_pd_boundary=0x7f3c7c2f5d40) at /data/src/bb-10.6-release/sql/opt_split.cc:1048
#5  0x000055b653619ba2 in best_access_path (join=0x7f3c24075e88, s=0x7f3c2407c160, remaining_tables=4, join_positions=0x7f3c2407cca8, idx=2, disable_jbuf=true, record_count=30, pos=0x7f3c2407cf38, loose_scan_pos=0x7f3c7c2f6180) at /data/src/bb-10.6-release/sql/sql_select.cc:7898
#6  0x000055b6537f56f8 in fix_semijoin_strategies_for_picked_join_order (join=0x7f3c24075e88) at /data/src/bb-10.6-release/sql/opt_subselect.cc:3994
#7  0x000055b653622f3d in JOIN::get_best_combination (this=0x7f3c24075e88) at /data/src/bb-10.6-release/sql/sql_select.cc:11183

choose_best_splitting() is called from fix_semijoin_strategies_for_picked_join_order().
The problem is that choose_best_splitting() assumes that the current join prefix is in join->positions, while at JOIN::get_best_combination()/fix_semijoin_strategies_for_picked_join_order() stage it is in join->best_positions.

Comment by Sergei Petrunia [ 2023-06-05 ]

bb-10.4-MDEV-31403

Comment by VAROQUI Stephane [ 2023-06-09 ]

Please reopen as of MDEV-31440

Comment by Richard DEMONGEOT [ 2023-08-30 ]

Hello, I just had an issue very similar - with a query on MariaDB 10.6.14

Environement : Debian 11 + jemalloc + Mariadb10.6.16

Thread pointer: 0x7fd601c97818
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 = 0x7fd6a2f7d4d8 thread_stack 0x30000
/usr/sbin/mariadbd(my_print_stacktrace+0x2e)[0x55888e0e75ae]
/usr/sbin/mariadbd(handle_fatal_signal+0x485)[0x55888dbb03d5]
sigaction.c:0(__restore_rt)[0x7fdb2333c140]
/usr/sbin/mariadbd(_ZN13st_join_table21choose_best_splittingEjyPK8POSITIONPy+0x564)[0x55888db2fcf4]
/usr/sbin/mariadbd(Z16best_access_pathP4JOINP13st_join_tableyPK8POSITIONjbdPS3_S6+0x14f)[0x55888d9b187f]
/usr/sbin/mariadbd(+0x7f561f)[0x55888d9b561f]
/usr/sbin/mariadbd(+0x7f58de)[0x55888d9b58de]
/usr/sbin/mariadbd(+0x7f58de)[0x55888d9b58de]
/usr/sbin/mariadbd(_Z11choose_planP4JOINy+0x2a4)[0x55888d9b6434]
/usr/sbin/mariadbd(+0x8206c1)[0x55888d9e06c1]
/usr/sbin/mariadbd(_ZN4JOIN14optimize_innerEv+0x12ec)[0x55888d9e53ac]
/usr/sbin/mariadbd(_ZN4JOIN8optimizeEv+0xa0)[0x55888d9e59c0]
/usr/sbin/mariadbd(_Z12mysql_selectP3THDP10TABLE_LISTR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0xb3)[0x55888d9e5a93]
/usr/sbin/mariadbd(_Z13handle_selectP3THDP3LEXP13select_resultm+0x14f)[0x55888d9e629f]
/usr/sbin/mariadbd(+0x7abfe1)[0x55888d96bfe1]
/usr/sbin/mariadbd(_Z21mysql_execute_commandP3THDb+0x4607)[0x55888d97b157]
/usr/sbin/mariadbd(_Z11mysql_parseP3THDPcjP12Parser_state+0x1e7)[0x55888d97c747]
/usr/sbin/mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0x156d)[0x55888d97ef4d]
/usr/sbin/mariadbd(_Z10do_commandP3THDb+0x138)[0x55888d980ae8]
/usr/sbin/mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x3af)[0x55888da8f61f]
/usr/sbin/mariadbd(handle_one_connection+0x5d)[0x55888da8f96d]
/usr/sbin/mariadbd(+0xc3c322)[0x55888ddfc322]
nptl/pthread_create.c:478(start_thread)[0x7fdb23330ea7]
x86_64/clone.S:97(_GI__clone)[0x7fdb22f37a2f]

Comment by Daniel Lenski [ 2024-01-25 ]

See https://jira.mariadb.org/browse/MDEV-31240?focusedCommentId=278585#comment-278585 for a viable mitigation for this crash and related ones in st_join_table::choose_best_splitting.
The mitigation is:

SET SESSION optimizer_switch='split_materialized=off';

Generated at Thu Feb 08 10:23:36 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.