Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-29294

OR from subquery: (SELECT x OR y) OR z: Assertion `functype() == ((Item_cond *) new_item)->functype()' failed

Details

    Description

      CREATE TABLE t (c INT);
      SELECT * FROM t WHERE c = 1 AND ( 3 = 0 OR  (SELECT c = 1 OR (SELECT 3 WHERE c = c ) = 3));
      

      Leads to:

      10.9.2 a5dc76a051ff908a5f506ed12e8d05311752e5fb (Debug)

      mysqld: /test/10.9_dbg/sql/sql_select.cc:17967: virtual COND* Item_cond::remove_eq_conds(THD*, Item::cond_result*, bool): Assertion `functype() == ((Item_cond *) new_item)->functype()' failed.
      

      10.9.2 a5dc76a051ff908a5f506ed12e8d05311752e5fb (Debug)

      Core was generated by `/test/MD190722-mariadb-10.9.2-linux-x86_64-dbg/bin/mysqld --no-defaults --core-'.
      Program terminated with signal SIGABRT, Aborted.
      #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
      [Current thread is 1 (Thread 0x14c6a80a3700 (LWP 519539))]
      (gdb) bt
      #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
      #1  0x000014c6bf03b859 in __GI_abort () at abort.c:79
      #2  0x000014c6bf03b729 in __assert_fail_base (fmt=0x14c6bf1d1588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x558c7d40aeb8 "functype() == ((Item_cond *) new_item)->functype()", file=0x558c7d409948 "/test/10.9_dbg/sql/sql_select.cc", line=17967, function=<optimized out>) at assert.c:92
      #3  0x000014c6bf04cfd6 in __GI___assert_fail (assertion=assertion@entry=0x558c7d40aeb8 "functype() == ((Item_cond *) new_item)->functype()", file=file@entry=0x558c7d409948 "/test/10.9_dbg/sql/sql_select.cc", line=line@entry=17967, function=function@entry=0x558c7d40aef0 "virtual COND* Item_cond::remove_eq_conds(THD*, Item::cond_result*, bool)") at assert.c:101
      #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
      

      Bug confirmed present in:
      MariaDB: 10.4.26 (dbg), 10.5.17 (dbg), 10.6.9 (dbg), 10.7.5 (dbg), 10.8.4 (dbg), 10.9.2 (dbg), 10.10.0 (dbg)

      Bug (or feature/syntax) confirmed not present in:
      MariaDB: 10.3.36 (dbg), 10.3.36 (opt), 10.4.26 (opt), 10.5.17 (opt), 10.6.9 (opt), 10.7.5 (opt), 10.8.4 (opt), 10.9.2 (opt), 10.10.0 (opt)

      Attachments

        Issue Links

          Activity

            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...

            psergei 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
            

            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.

            psergei 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.
            oleg.smirnov Oleg Smirnov added a comment -

            Please review the patch suggested in bb-10.4-MDEV-29294.

            oleg.smirnov Oleg Smirnov added a comment - Please review the patch suggested in bb-10.4- MDEV-29294 .

            Review input provided on Slack...

            psergei Sergei Petrunia added a comment - Review input provided on Slack...
            oleg.smirnov Oleg Smirnov added a comment -

            The fix has been pushed into 10.4.

            oleg.smirnov Oleg Smirnov added a comment - The fix has been pushed into 10.4.

            People

              psergei Sergei Petrunia
              ramesh Ramesh Sivaraman
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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