#4 0x0000558c7c86b210 in Item_cond::remove_eq_conds (this=0x14c67001ff90, thd=0x14c670000db8, cond_value=0x14c670020d00, top_level_arg=<optimized out>) at /test/10.9_dbg/sql/sql_select.cc:17967
#5 0x0000558c7c8524f3 in optimize_cond (join=join@entry=0x14c6700209a8, conds=0x14c67001ff90, join_list=0x14c670013ef0, ignore_on_conds=ignore_on_conds@entry=false, cond_value=cond_value@entry=0x14c670020d00, cond_equal=cond_equal@entry=0x14c670020e28, flags=1) at /test/10.9_dbg/sql/sql_select.cc:17676
#6 0x0000558c7c897883 in JOIN::optimize_inner (this=this@entry=0x14c6700209a8) at /test/10.9_dbg/sql/sql_select.cc:2231
#7 0x0000558c7c8986ee in JOIN::optimize (this=this@entry=0x14c6700209a8) at /test/10.9_dbg/sql/sql_select.cc:1846
#8 0x0000558c7c8987e1 in mysql_select (thd=thd@entry=0x14c670000db8, tables=0x14c670014310, fields=@0x14c670013fd8: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x14c6700142c8, last = 0x14c6700142c8, elements = 1}, <No data fields>}, conds=0x14c67001ff90, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x14c670020980, unit=0x14c670004fd8, select_lex=0x14c670013d38) at /test/10.9_dbg/sql/sql_select.cc:5031
#9 0x0000558c7c89902a in handle_select (thd=thd@entry=0x14c670000db8, lex=lex@entry=0x14c670004f00, result=result@entry=0x14c670020980, setup_tables_done_option=setup_tables_done_option@entry=0) at /test/10.9_dbg/sql/sql_select.cc:579
#10 0x0000558c7c803fde in execute_sqlcom_select (thd=thd@entry=0x14c670000db8, all_tables=0x14c670014310) at /test/10.9_dbg/sql/sql_parse.cc:6260
#11 0x0000558c7c8102fc in mysql_execute_command (thd=thd@entry=0x14c670000db8, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/10.9_dbg/sql/sql_parse.cc:3944
#12 0x0000558c7c7fe2ba in mysql_parse (thd=thd@entry=0x14c670000db8, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x14c6a80a2470) at /test/10.9_dbg/sql/sql_parse.cc:8036
#13 0x0000558c7c80b8b0 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x14c670000db8, packet=packet@entry=0x14c67000b6c9 "SELECT * FROM t WHERE c = 1 AND ( 3 = 0 OR (SELECT c = 1 OR (SELECT 3 WHERE c = c ) = 3))", packet_length=packet_length@entry=91, blocking=blocking@entry=true) at /test/10.9_dbg/sql/sql_class.h:1364
#14 0x0000558c7c80dfb8 in do_command (thd=0x14c670000db8, blocking=blocking@entry=true) at /test/10.9_dbg/sql/sql_parse.cc:1407
#15 0x0000558c7c96f6c2 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x558c80133b08, put_in_cache=put_in_cache@entry=true) at /test/10.9_dbg/sql/sql_connect.cc:1418
#16 0x0000558c7c96fbcb in handle_one_connection (arg=0x558c80133b08) at /test/10.9_dbg/sql/sql_connect.cc:1312
#17 0x000014c6bf54c609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#18 0x000014c6bf138133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
MDEV-28506SIGSEGV's in find_field_in_table[s][_ref], Item_field::fix_fields, create_view_field and MemcmpInterceptorCommon | Assertions `(*select_ref)->fixed' or '->is_fixed' and `table_list->table' failed
WHERE c = 1 AND ( 3 = 0 OR (SELECT c = 1 OR (SELECT 3 WHERE c = c ) = 3));
The WHERE has form: "c=1 AND (...)". The right part of that condition is:
3 = 0
OR
(SELECT c = 1 OR (SELECT 3 WHERE c = c ) = 3)
Line #3 is a degenerate subquery in form "(SELECT foo)" which gets rewritten to just "foo":
3 = 0
OR
(
c = 1
OR
(SELECT 3 WHERE c = c ) = 3
)
And this is how we get OR-inside-another-OR.
Could it be that this bug is caused by the code that does the "(SELECT foo)" -> "foo" rewrite? It does the rewrite and accidentally creates OR-inside-OR...
Sergei Petrunia
added a comment - Looking at the original query:
WHERE c = 1 AND ( 3 = 0 OR (SELECT c = 1 OR (SELECT 3 WHERE c = c ) = 3));
The WHERE has form: " c=1 AND (...) ". The right part of that condition is:
3 = 0
OR
(SELECT c = 1 OR (SELECT 3 WHERE c = c ) = 3)
Line #3 is a degenerate subquery in form "(SELECT foo)" which gets rewritten to just "foo":
3 = 0
OR
(
c = 1
OR
(SELECT 3 WHERE c = c ) = 3
)
And this is how we get OR-inside-another-OR.
Could it be that this bug is caused by the code that does the "(SELECT foo)" -> "foo" rewrite? It does the rewrite and accidentally creates OR-inside-OR...
The rewrite in question happens in Item_singlerow_subselect::select_transformer().
Item_subselect::fix_fields( ..., Item *ref) puts an Item_cond_or into *ref.
Then, here:
#0 Item_cond::fix_fields (this=0x7fff8401a8f0, thd=0x7fff84000d78, ref=0x7fff8401ab00) at /home/psergey/dev-git2/10.6-fix/sql/item_cmpfunc.cc:4974
#1 0x0000555555d8c196 in Item::fix_fields_if_needed (this=0x7fff8401a8f0, thd=0x7fff84000d78, ref=0x7fff8401ab00) at /home/psergey/dev-git2/10.6-fix/sql/item.h:1147
#2 0x0000555555d8c1c3 in Item::fix_fields_if_needed_for_scalar (this=0x7fff8401a8f0, thd=0x7fff84000d78, ref=0x7fff8401ab00) at /home/psergey/dev-git2/10.6-fix/sql/item.h:1156
#3 0x0000555555e154b3 in Item::fix_fields_if_needed_for_bool (this=0x7fff8401a8f0, thd=0x7fff84000d78, ref=0x7fff8401ab00) at /home/psergey/dev-git2/10.6-fix/sql/item.h:1160
#4 0x00005555562a4712 in Item_cond::fix_fields (this=0x7fff8401a9e8, thd=0x7fff84000d78, ref=0x7fff8401b8d8) at /home/psergey/dev-git2/10.6-fix/sql/item_cmpfunc.cc:4971
#5 0x0000555555d8c196 in Item::fix_fields_if_needed (this=0x7fff8401a9e8, thd=0x7fff84000d78, ref=0x7fff8401b8d8) at /home/psergey/dev-git2/10.6-fix/sql/item.h:1147
#6 0x0000555555d8c1c3 in Item::fix_fields_if_needed_for_scalar (this=0x7fff8401a9e8, thd=0x7fff84000d78, ref=0x7fff8401b8d8) at /home/psergey/dev-git2/10.6-fix/sql/item.h:1156
#7 0x0000555555e154b3 in Item::fix_fields_if_needed_for_bool (this=0x7fff8401a9e8, thd=0x7fff84000d78, ref=0x7fff8401b8d8) at /home/psergey/dev-git2/10.6-fix/sql/item.h:1160
#8 0x0000555555e11bd7 in setup_conds (thd=0x7fff84000d78, tables=0x7fff84017110, leaves=..., conds=0x7fff8401b8d8) at /home/psergey/dev-git2/10.6-fix/sql/sql_base.cc:8542
#9 0x0000555555efa758 in setup_without_group (thd=0x7fff84000d78, ref_pointer_array=..., tables=0x7fff84017110, leaves=..., fields=..., all_fields=..., conds=0x7fff8401b8d8, order=0x0, group=0x0, win_specs=..., win_funcs=..., hidden_group_fields=0x7fff8401b7af, reserved=0x7fff84016eec) at /home/psergey/dev-git2/10.6-fix/sql/sql_select.cc:857
item= *li.ref(); // item can be substituted in fix_fields
and
(gdb) print item
$173 = (Item_cond_or *) 0x7fff84019d80
Fix suggestion: if we are an Item_cond_or and we've got an Item_cond_or as a child (=$new_child), concatenate $new_child->list to this->list. Also, do the same if both are Item_cond_and-s.
Sergei Petrunia
added a comment -
The rewrite in question happens in Item_singlerow_subselect::select_transformer().
Item_subselect::fix_fields( ..., Item *ref) puts an Item_cond_or into *ref.
Then, here:
#0 Item_cond::fix_fields (this=0x7fff8401a8f0, thd=0x7fff84000d78, ref=0x7fff8401ab00) at /home/psergey/dev-git2/10.6-fix/sql/item_cmpfunc.cc:4974
#1 0x0000555555d8c196 in Item::fix_fields_if_needed (this=0x7fff8401a8f0, thd=0x7fff84000d78, ref=0x7fff8401ab00) at /home/psergey/dev-git2/10.6-fix/sql/item.h:1147
#2 0x0000555555d8c1c3 in Item::fix_fields_if_needed_for_scalar (this=0x7fff8401a8f0, thd=0x7fff84000d78, ref=0x7fff8401ab00) at /home/psergey/dev-git2/10.6-fix/sql/item.h:1156
#3 0x0000555555e154b3 in Item::fix_fields_if_needed_for_bool (this=0x7fff8401a8f0, thd=0x7fff84000d78, ref=0x7fff8401ab00) at /home/psergey/dev-git2/10.6-fix/sql/item.h:1160
#4 0x00005555562a4712 in Item_cond::fix_fields (this=0x7fff8401a9e8, thd=0x7fff84000d78, ref=0x7fff8401b8d8) at /home/psergey/dev-git2/10.6-fix/sql/item_cmpfunc.cc:4971
#5 0x0000555555d8c196 in Item::fix_fields_if_needed (this=0x7fff8401a9e8, thd=0x7fff84000d78, ref=0x7fff8401b8d8) at /home/psergey/dev-git2/10.6-fix/sql/item.h:1147
#6 0x0000555555d8c1c3 in Item::fix_fields_if_needed_for_scalar (this=0x7fff8401a9e8, thd=0x7fff84000d78, ref=0x7fff8401b8d8) at /home/psergey/dev-git2/10.6-fix/sql/item.h:1156
#7 0x0000555555e154b3 in Item::fix_fields_if_needed_for_bool (this=0x7fff8401a9e8, thd=0x7fff84000d78, ref=0x7fff8401b8d8) at /home/psergey/dev-git2/10.6-fix/sql/item.h:1160
#8 0x0000555555e11bd7 in setup_conds (thd=0x7fff84000d78, tables=0x7fff84017110, leaves=..., conds=0x7fff8401b8d8) at /home/psergey/dev-git2/10.6-fix/sql/sql_base.cc:8542
#9 0x0000555555efa758 in setup_without_group (thd=0x7fff84000d78, ref_pointer_array=..., tables=0x7fff84017110, leaves=..., fields=..., all_fields=..., conds=0x7fff8401b8d8, order=0x0, group=0x0, win_specs=..., win_funcs=..., hidden_group_fields=0x7fff8401b7af, reserved=0x7fff84016eec) at /home/psergey/dev-git2/10.6-fix/sql/sql_select.cc:857
we have:
(gdb) p this
$171 = (Item_cond_or * const) 0x7fff8401a8f0
(gdb) print item
$172 = (Item_singlerow_subselect *) 0x7fff8401a728
this line is executed:
item= *li.ref(); // item can be substituted in fix_fields
and
(gdb) print item
$173 = (Item_cond_or *) 0x7fff84019d80
Fix suggestion: if we are an Item_cond_or and we've got an Item_cond_or as a child (=$new_child), concatenate $new_child->list to this->list. Also, do the same if both are Item_cond_and-s.
Looking at the original query:
WHERE c = 1 AND ( 3 = 0 OR (SELECT c = 1 OR (SELECT 3 WHERE c = c ) = 3));
The WHERE has form: "c=1 AND (...)". The right part of that condition is:
3 = 0
OR
(SELECT c = 1 OR (SELECT 3 WHERE c = c ) = 3)
Line #3 is a degenerate subquery in form "(SELECT foo)" which gets rewritten to just "foo":
3 = 0
OR
(
c = 1
OR
(SELECT 3 WHERE c = c ) = 3
)
And this is how we get OR-inside-another-OR.
Could it be that this bug is caused by the code that does the "(SELECT foo)" -> "foo" rewrite? It does the rewrite and accidentally creates OR-inside-OR...