[MDEV-5811] Server crashes in best_access_path with materialization+semijoin and big_tables=ON Created: 2014-03-10  Updated: 2014-03-18  Resolved: 2014-03-18

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 5.3.12, 5.5.36, 10.0.9
Fix Version/s: 5.5.37, 10.0.10, 5.3.13

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Sergei Petrunia
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates

 Description   

SET optimizer_switch = 'materialization=on,semijoin=on';
SET big_tables = ON;
 
CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1),(2);
 
CREATE TABLE t2 (b INT);
INSERT INTO t2 VALUES (3),(4);
 
SELECT * FROM t1 AS t1_1, t1 AS t1_2 
  WHERE ( t1_1.a, t1_2.a ) IN ( SELECT MAX(b), MIN(b) FROM t2 );

#3  <signal handler called>
#4  0x0000000000735f36 in best_access_path (join=0x397d768, s=0x39f4bd0, remaining_tables=6, idx=1, disable_jbuf=false, record_count=2, pos=0x39f4ff8, loose_scan_pos=0x7f48972b1da0) at sql_select.cc:5477
#5  0x0000000000738f1c in best_extension_by_limited_search (join=0x397d768, remaining_tables=6, idx=1, record_count=2, read_time=2.4034179687499999, search_depth=61, prune_level=1) at sql_select.cc:6777
#6  0x00000000007392b9 in best_extension_by_limited_search (join=0x397d768, remaining_tables=7, idx=0, record_count=1, read_time=0, search_depth=62, prune_level=1) at sql_select.cc:6838
#7  0x00000000007383ee in greedy_search (join=0x397d768, remaining_tables=7, search_depth=62, prune_level=1) at sql_select.cc:6394
#8  0x0000000000737a50 in choose_plan (join=0x397d768, join_tables=7) at sql_select.cc:5982
#9  0x0000000000731443 in make_join_statistics (join=0x397d768, tables_list=..., conds=0x3984878, keyuse_array=0x397da48) at sql_select.cc:3694
#10 0x000000000072847c in JOIN::optimize (this=0x397d768) at sql_select.cc:1165
#11 0x000000000072ee2d in mysql_select (thd=0x38c6b88, rref_pointer_array=0x38c9878, tables=0x394ab58, wild_num=1, fields=..., conds=0x397d520, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147764992, result=0x397d748, unit=0x38c9118, select_lex=0x38c9620) at sql_select.cc:2993
#12 0x0000000000725929 in handle_select (thd=0x38c6b88, lex=0x38c9078, result=0x397d748, setup_tables_done_option=0) at sql_select.cc:288
#13 0x00000000006b457c in execute_sqlcom_select (thd=0x38c6b88, all_tables=0x394ab58) at sql_parse.cc:5172
#14 0x00000000006ab718 in mysql_execute_command (thd=0x38c6b88) at sql_parse.cc:2305
#15 0x00000000006b6ee3 in mysql_parse (thd=0x38c6b88, rawbuf=0x394a8c0 "SELECT * FROM t1 AS t1_1, t1 AS t1_2 WHERE ( t1_1.a, t1_2.a ) IN ( SELECT MAX(b), MIN(b) FROM t2 )", length=98, found_semicolon=0x7f48972b3cb8) at sql_parse.cc:6173
#16 0x00000000006a8ef8 in dispatch_command (command=COM_QUERY, thd=0x38c6b88, packet=0x3941459 "SELECT * FROM t1 AS t1_1, t1 AS t1_2 WHERE ( t1_1.a, t1_2.a ) IN ( SELECT MAX(b), MIN(b) FROM t2 )", packet_length=98) at sql_parse.cc:1243
#17 0x00000000006a81e4 in do_command (thd=0x38c6b88) at sql_parse.cc:923
#18 0x00000000006a5075 in handle_one_connection (arg=0x38c6b88) at sql_connect.cc:1231
#19 0x00007f48a0aa2b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#20 0x00007f489fe45a7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Stack trace from:

revision-id: sanja@montyprogram.com-20140307115707-poaet8iwv9d55azm
date: 2014-03-07 13:57:07 +0200
build-date: 2014-03-10 21:21:12 +0400
revno: 3767
branch-nick: 5.3

EXPLAIN also crashes.



 Comments   
Comment by Sergei Petrunia [ 2014-03-13 ]

I'm debugging the SELECT with big_tables=ON and big_tables=OFF:

Breakpoint 4, best_access_path (join=0x7fffcd04b9d0, s=0x7fffcd0c6280, remaining_tables=1, idx=0, disable_jbuf=false, record_count=1, pos=0x7fffcd0c67b0, loose_scan_pos=0x7ffff7ee8a90) at /home/psergey/dev2/5.5/sql/sql_select.cc:5379
$153 = 0
$154 = 0x7fffcd01d3f0 "t2"
(gdb) c
Continuing.

Breakpoint 4, best_access_path (join=0x7fffcd04b0b0, s=0x7fffcd0f4040, remaining_tables=7, idx=0, disable_jbuf=false, record_count=1, pos=0x7fffcd0f4be0, loose_scan_pos=0x7ffff7ee8d40) at /home/psergey/dev2/5.5/sql/sql_select.cc:5379
$155 = 0
$156 = 0x7fffcd01d1c0 "t1_1"
(gdb) c
Continuing.

Breakpoint 4, best_access_path (join=0x7fffcd04b0b0, s=0x7fffcd0f4680, remaining_tables=6, idx=1, disable_jbuf=false, record_count=2, pos=0x7fffcd0f4ce0, loose_scan_pos=0x7ffff7ee8b50) at /home/psergey/dev2/5.5/sql/sql_select.cc:5379
$157 = 1
$158 = 0x7fffcd0c90e8 "<subquery2>"

The execution starts to differ in this best_access_path() call.

Here, we consider a ref access to table <subquery2>. The WHERE has IN-equalities:
t1_1.a=MAX(b) AND t1_2.a=MIN(b)

the prefix has only table t1_1.

without big_tables, the temp.table is a ha_heap table and it has

(table->file->index_flags(key, 0, 0) & HA_ONLY_WHOLE_INDEX)

With big_tables=1, partial index reads are allowed, and we proceed further and then crash because key_info->rec_per_key=NULL.

Comment by Sergei Petrunia [ 2014-03-13 ]

Committed a patch.

Comment by Sergei Petrunia [ 2014-03-18 ]

Pushed into 5.3.

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