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

server crashes in base_list_iterator::next

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.2(EOL), 10.3(EOL)
    • 10.3.11, 10.2.19
    • Optimizer
    • None

    Description

      CREATE TABLE t1(i int);
      SELECT DISTINCT BIT_AND(0) OVER (), MAX(1) FROM t1;
      

       10.2 ba10ffe0f4c94c0fd2b1e4261
      Thread 1 (Thread 0x7f4f0827c700 (LWP 10291)):
      #0  __pthread_kill (threadid=<optimized out>, signo=11) at ../sysdeps/unix/sysv/linux/pthread_kill.c:62
      #1  0x000055a2982b0da4 in my_write_core (sig=11) at /10.2/mysys/stacktrace.c:477
      #2  0x000055a297b49815 in handle_fatal_signal (sig=11) at /10.2/sql/signal_handler.cc:305
      #3  <signal handler called>
      #4  0x000055a29785a338 in base_list_iterator::next (this=0x7f4f08279c00) at /10.2/sql/sql_list.h:451
      #5  0x000055a2978769c3 in List_iterator<Item>::operator++ (this=0x7f4f08279c00) at /10.2/sql/sql_list.h:564
      #6  0x000055a29794d768 in st_join_table::remove_duplicates (this=0x7f4ef8013ec8) at /10.2/sql/sql_select.cc:21975
      #7  0x000055a2979479e7 in join_init_read_record (tab=0x7f4ef8013ec8) at /10.2/sql/sql_select.cc:19635
      #8  0x000055a29795a379 in AGGR_OP::end_send (this=0x7f4ef80144f8) at /10.2/sql/sql_select.cc:26632
      #9  0x000055a2979454fd in sub_select_postjoin_aggr (join=0x7f4ef8013420, join_tab=0x7f4ef8013ec8, end_of_records=true) at /10.2/sql/sql_select.cc:18450
      #10 0x000055a297945039 in do_select (join=0x7f4ef8013420, procedure=0x0) at /10.2/sql/sql_select.cc:18281
      #11 0x000055a29791fa65 in JOIN::exec_inner (this=0x7f4ef8013420) at /10.2/sql/sql_select.cc:3602
      #12 0x000055a29791ef14 in JOIN::exec (this=0x7f4ef8013420) at /10.2/sql/sql_select.cc:3397
      #13 0x000055a2979200d6 in mysql_select (thd=0x7f4ef8000b00, tables=0x7f4ef8012d10, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748609, result=0x7f4ef8013400, unit=0x7f4ef80046d8, select_lex=0x7f4ef8004e10) at /10.2/sql/sql_select.cc:3797
      #14 0x000055a29791443e in handle_select (thd=0x7f4ef8000b00, lex=0x7f4ef8004610, result=0x7f4ef8013400, setup_tables_done_option=0) at /10.2/sql/sql_select.cc:376
      #15 0x000055a2978dfb7c in execute_sqlcom_select (thd=0x7f4ef8000b00, all_tables=0x7f4ef8012d10) at /10.2/sql/sql_parse.cc:6477
      #16 0x000055a2978d58ba in mysql_execute_command (thd=0x7f4ef8000b00) at /10.2/sql/sql_parse.cc:3484
      #17 0x000055a2978e3992 in mysql_parse (thd=0x7f4ef8000b00, rawbuf=0x7f4ef8012478 "SELECT DISTINCT BIT_AND(0) OVER () AS field1,\nMAX(1) AS field2\nFROM t8", length=70, parser_state=0x7f4f0827b080, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:8009
      #18 0x000055a2978d112d in dispatch_command (command=COM_QUERY, thd=0x7f4ef8000b00, packet=0x7f4ef808c0c1 "", packet_length=70, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:1824
      #19 0x000055a2978cfa89 in do_command (thd=0x7f4ef8000b00) at /10.2/sql/sql_parse.cc:1378
      #20 0x000055a297a20ddd in do_handle_one_connection (connect=0x55a29a518d70) at /10.2/sql/sql_connect.cc:1335
      #21 0x000055a297a20b5d in handle_one_connection (arg=0x55a29a518d70) at /10.2/sql/sql_connect.cc:1241
      #22 0x000055a29824e454 in pfs_spawn_thread (arg=0x55a29a5bb570) at /10.2/storage/perfschema/pfs.cc:1862
      #23 0x00007f4f0fa346ba in start_thread (arg=0x7f4f0827c700) at pthread_create.c:333
      #24 0x00007f4f0eec941d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
      

      Attachments

        Issue Links

          Activity

            varun Varun Gupta (Inactive) added a comment - - edited

            This is another case of the problem we had in MDEV-13352

            The explanation there was
            join_tab->distinct=true means "Before doing record read with this
            join_tab, call join_tab->remove_duplicates() to eliminate duplicates".
            remove_duplicates() assumes that
            - there is a temporary table $T with rows that are to be de-duplicated
            - there is a previous join_tab (e.g. with join_tab->fields) which was
            used to populate the temp.table $T.
             
            When the query has "Impossible WHERE" and window function, then the above
            conditions are not met (but we still might need a window function
            computation step when the query has implicit grouping).
             
            The fix is to not add remove_duplicates step if the select execution is
            degenerate (and we'll have at most one row in the output anyway).
            

            For our case also we have MAX function with no GROUP BY so we will only return one row so there is no point of computing DISTINCT

            varun Varun Gupta (Inactive) added a comment - - edited This is another case of the problem we had in MDEV-13352 The explanation there was join_tab->distinct=true means "Before doing record read with this join_tab, call join_tab->remove_duplicates() to eliminate duplicates". remove_duplicates() assumes that - there is a temporary table $T with rows that are to be de-duplicated - there is a previous join_tab (e.g. with join_tab->fields) which was used to populate the temp.table $T.   When the query has "Impossible WHERE" and window function, then the above conditions are not met (but we still might need a window function computation step when the query has implicit grouping).   The fix is to not add remove_duplicates step if the select execution is degenerate (and we'll have at most one row in the output anyway). For our case also we have MAX function with no GROUP BY so we will only return one row so there is no point of computing DISTINCT
            varun Varun Gupta (Inactive) added a comment - - edited Patch http://lists.askmonty.org/pipermail/commits/2018-September/012908.html

            table_list is used instead of table_count, because by table_count=0 we mean that there would be no result and all we need to do if we have a case of implicit grouping then we add a NULL row to the result.

            With table_list we mean that all items are resolved but we need to still return a row in the result which is not a NULL row.

            varun Varun Gupta (Inactive) added a comment - table_list is used instead of table_count, because by table_count=0 we mean that there would be no result and all we need to do if we have a case of implicit grouping then we add a NULL row to the result. With table_list we mean that all items are resolved but we need to still return a row in the result which is not a NULL row.

            Ok to push.

            psergei Sergei Petrunia added a comment - Ok to push.

            People

              varun Varun Gupta (Inactive)
              alice Alice Sherepa
              Votes:
              0 Vote for this issue
              Watchers:
              3 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.