[MDEV-405] Server crashes in test_if_skip_sort_order on EXPLAIN with GROUP BY and HAVING in EXISTS subquery Created: 2012-07-19  Updated: 2012-08-28  Resolved: 2012-08-28

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 5.5.25
Fix Version/s: 5.5.27

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Sergei Petrunia
Resolution: Duplicate Votes: 0
Labels: None


 Description   

 
#2  0x00000000007bf65c in handle_fatal_signal (sig=11) at sql/signal_handler.cc:279
#3  <signal handler called>
#4  0x0000000000669c2f in test_if_skip_sort_order (tab=0x35c4570, order=0x35bf238, select_limit=1, no_changes=false, map=0x35c0e80) at sql/sql_select.cc:18605
#5  0x0000000000641d94 in JOIN::exec (this=0x35c0578) at sql/sql_select.cc:2330
#6  0x0000000000644581 in mysql_select (thd=0x34a56a0, rref_pointer_array=0x35a89a8, tables=0x35a92c0, wild_num=0, fields=..., conds=0x35c3078, og_num=1, order=0x0, group=0x35bf238, having=0x35bf408, proc_param=0x0, select_options=2147748612, result=0x35bf788, unit=0x35a8a98, select_lex=0x35a8750) at sql/sql_select.cc:3044
#7  0x0000000000672e7c in mysql_explain_union (thd=0x34a56a0, unit=0x35a8a98, result=0x35bf788) at sql/sql_select.cc:21914
#8  0x0000000000672b93 in select_describe (join=0x35bfe48, need_tmp_table=false, need_order=false, distinct=false, message=0xd2f7cf "Impossible WHERE") at sql/sql_select.cc:21871
#9  0x0000000000657a81 in return_zero_rows (join=0x35bfe48, result=0x35bf788, tables=..., fields=..., send_row=false, select_options=2147748612, info=0xd2f7cf "Impossible WHERE", having=0x0, all_fields=...) at sql/sql_select.cc:10994
#10 0x0000000000641a43 in JOIN::exec (this=0x35bfe48) at sql/sql_select.cc:2277
#11 0x0000000000644581 in mysql_select (thd=0x34a56a0, rref_pointer_array=0x34a8358, tables=0x35a8170, wild_num=1, fields=..., conds=0x35bf578, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748612, result=0x35bf788, unit=0x34a7a28, select_lex=0x34a8100) at sql/sql_select.cc:3044
#12 0x0000000000672e7c in mysql_explain_union (thd=0x34a56a0, unit=0x34a7a28, result=0x35bf788) at sql/sql_select.cc:21914
#13 0x0000000000614255 in execute_sqlcom_select (thd=0x34a56a0, all_tables=0x35a8170) at sql/sql_parse.cc:4592
#14 0x000000000060cf7e in mysql_execute_command (thd=0x34a56a0) at sql/sql_parse.cc:2189
#15 0x0000000000616ca1 in mysql_parse (thd=0x34a56a0, rawbuf=0x35a7ee8 "EXPLAIN SELECT * FROM t1 WHERE EXISTS ( SELECT a FROM t1, t2 WHERE b = a GROUP BY a HAVING a <> 1 )", length=99, parser_state=0x7f831f63d500) at sql/sql_parse.cc:5736
#16 0x000000000060a517 in dispatch_command (command=COM_QUERY, thd=0x34a56a0, packet=0x35a06d1 "", packet_length=100) at sql/sql_parse.cc:1055
#17 0x00000000006097ce in do_command (thd=0x34a56a0) at sql/sql_parse.cc:794
#18 0x000000000070ac27 in do_handle_one_connection (thd_arg=0x34a56a0) at sql/sql_connect.cc:1253
#19 0x000000000070a612 in handle_one_connection (arg=0x34a56a0) at sql/sql_connect.cc:1168
#20 0x0000000000c015ef in pfs_spawn_thread (arg=0x3629100) at storage/perfschema/pfs.cc:1015
#21 0x00007f832ac9aefc in start_thread (arg=0x7f831f63e700) at pthread_create.c:304
#22 0x00007f832a00d59d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

bzr version-info

revision-id: axel@mysql.com-20120719112424-dszclm7cekcji8bw
date: 2012-07-19 13:24:24 +0200
build-date: 2012-07-20 00:36:09 +0400
revno: 3470

I suppose it's a regression from MDEV-193, as it appeared with revno 3445 (reproducible on 3445, not reproducible on 3444).

Reproducible with MyISAM, Aria, InnoDB;.

Minimal optimizer_switch:
in_to_exists=on

Full optimizer_switch (default):

index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=off

Test case:

CREATE TABLE t1 (a INT, KEY(a));
INSERT INTO t1 VALUES (1),(8);
 
CREATE TABLE t2 (b INT, KEY(b));
INSERT INTO t2 VALUES (45),(17),(20);
 
EXPLAIN SELECT * FROM t1 WHERE EXISTS ( SELECT a FROM t1, t2 WHERE b = a GROUP BY a HAVING a <> 1 ) ;



 Comments   
Comment by Timour Katchaounov (Inactive) [ 2012-08-21 ]

Analysis:

  • The subquery is a cheap constant subquery, so the subquery is executed by the outer query as follows:

#0 JOIN::exec (this=0x333b0b8) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:2182
#1 0x000000000086a227 in subselect_single_select_engine::exec (this=0x333a1e0) at /home/tsk/mprog/src/5.5/sql/item_subselect.cc:3167
#2 0x0000000000862f1b in Item_subselect::exec (this=0x333a0b8) at /home/tsk/mprog/src/5.5/sql/item_subselect.cc:640
#3 0x00000000008653e7 in Item_exists_subselect::val_int (this=0x333a0b8) at /home/tsk/mprog/src/5.5/sql/item_subselect.cc:1466
#4 0x0000000000829ecc in eval_const_cond (cond=0x333a0b8) at /home/tsk/mprog/src/5.5/sql/item_func.cc:80
#5 0x0000000000677544 in internal_remove_eq_conds (thd=0x322f080, cond=0x333a0b8, cond_value=0x333ac70) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:13434
#6 0x0000000000677888 in remove_eq_conds (thd=0x322f080, cond=0x333a0b8, cond_value=0x333ac70) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:13526
#7 0x0000000000676f11 in optimize_cond (join=0x333a988, conds=0x333a0b8, join_list=0x3231c50, cond_value=0x333ac70, cond_equal=0x333ad90) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:13292
#8 0x0000000000658395 in JOIN::optimize (this=0x333a988) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:1069

  • At the end of the executing the subquery do_select for the subquery calls JOIN_TAB::cleanup as follows:

#0 st_join_table::cleanup (this=0x3348a90) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:10239
#1 0x000000000067167f in JOIN::cleanup (this=0x333fb48, full=true) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:10617
#2 0x0000000000671387 in JOIN::join_free (this=0x333fb48) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:10534
#3 0x000000000067dd22 in do_select (join=0x333fb48, fields=0x333fec8, table=0x0, procedure=0x0) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:15807
#4 0x000000000065eb9c in JOIN::exec (this=0x333fb48) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:2830

  • As a result, JOIN_TAB::cleanup deletes JOIN_TAB::select and sets it to NULL.
  • Then execution proceeds to complete the EXPLAIN, and executes the subquery one more time

#0 0x00000000006844d7 in test_if_skip_sort_order (tab=0x3348a90, order=0x333e808, select_limit=2, no_changes=false, map=0x3340450) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:18613
#1 0x000000000065cd62 in JOIN::exec (this=0x333fb48) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:2336
#2 0x000000000065f393 in mysql_select (thd=0x322f080, rref_pointer_array=0x3329b08, tables=0x332a420, wild_num=0, fields=..., conds=0x3347598, og_num=1, order=0x0, group=0x333e808, having=0x333e9d8, proc_param=0x0, select_options=2147748612, result=0x333ed58, unit=0x3329bf8, select_lex=0x33298b0) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:3050
#3 0x000000000068d4f7 in mysql_explain_union (thd=0x322f080, unit=0x3329bf8, result=0x333ed58) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:21948
#4 0x000000000068d222 in select_describe (join=0x333f418, need_tmp_table=false, need_order=false, distinct=false, message=0xd0cf3f "Impossible WHERE") at /home/tsk/mprog/src/5.5/sql/sql_select.cc:21905
#5 0x0000000000672541 in return_zero_rows (join=0x333f418, result=0x333ed58, tables=..., fields=..., send_row=false, select_options=2147748612, info=0xd0cf3f "Impossible WHERE", having=0x0, all_fields=...) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:11001
#6 0x000000000065ca11 in JOIN::exec (this=0x333f418) at /home/tsk/mprog/src/5.5/sql/sql_select.cc:2283

  • At this point test_if_skip_sort_order crashes because tab->select was already set to NULL by JOIN_TAB::cleanup.
Comment by Sergei Petrunia [ 2012-08-28 ]

Seems to be similar to MDEV-430.

Comment by Sergei Petrunia [ 2012-08-28 ]

Duplicate of MDEV-430. Pushed the testscase.

Generated at Thu Feb 08 06:28:30 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.