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

Derived subquery selecting from dummy table causes segv

Details

    Description

      CREATE TABLE v0 ( v1 INTEGER ) ENGINE = InnoDB ;
      		 
      INSERT INTO v0 ( v1 ) ( SELECT 2231626 <= NULL v1 FROM v0 WHERE v1 IN ( v1 ) ORDER BY v1 ) ORDER BY v1 , AVG ( v1 ) OVER ( ) DESC ;
      		 
      DROP SHOW CREATE TABLE v0 ; 


      Attempting backtrace. You can use the following information to find out
      		 
      where mysqld died. If you see no messages after this, something went
      		 
      terribly wrong...
      		 
      stack_bottom = 0x7f1f87d04880 thread_stack 0x5fc00
      		 
      /usr/local/mysql/bin/mariadbd(__interceptor_backtrace+0x5b)[0x781b5b]
      		 
      mysys/stacktrace.c:215(my_print_stacktrace)[0x228cfae]
      		 
      sql/signal_handler.cc:0(handle_fatal_signal)[0x12bd0d2]
      		 
      sigaction.c:0(__restore_rt)[0x7f1faba9a420]
      		 
      sql/item.cc:3028(Item_field)[0x1315c2a]
      		 
      sql/sql_window.cc:3135(Window_funcs_sort::setup(THD*, SQL_SELECT*, List_iterator<Item_window_func>&, st_join_table*))[0x1113ef3]
      		 
      sql/sql_window.cc:3174(Window_funcs_computation::setup(THD*, List<Item_window_func>*, st_join_table*))[0x1115585]
      		 
      /usr/local/mysql/bin/mariadbd(_ZN4JOIN21make_aggr_tables_infoEv+0x3d67)[0xc34837]
      		 
      /usr/local/mysql/bin/mariadbd(_ZN4JOIN15optimize_stage2Ev+0xc891)[0xc0c5d1]
      		 
      /usr/local/mysql/bin/mariadbd(_ZN4JOIN14optimize_innerEv+0x3919)[0xc17249]
      		 
      /usr/local/mysql/bin/mariadbd(_ZN4JOIN8optimizeEv+0x176)[0xbffb46]
      		 
      sql/sql_derived.cc:1037(mysql_derived_optimize(THD*, LEX*, TABLE_LIST*))[0xa5bf21]
      		 
      /usr/local/mysql/bin/mariadbd(_Z27mysql_handle_single_derivedP3LEXP10TABLE_LISTj+0x172)[0xa5f042]
      		 
      /usr/local/mysql/bin/mariadbd(_ZN4JOIN14optimize_innerEv+0x3138)[0xc16a68]
      		 
      /usr/local/mysql/bin/mariadbd(_ZN4JOIN8optimizeEv+0x176)[0xbffb46]
      		 
      sql/sql_select.cc:5237(mysql_select(THD*, TABLE_LIST*, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0xbe886f]
      		 
      sql/sql_select.cc:628(handle_select(THD*, LEX*, select_result*, unsigned long long))[0xbe7e59]
      		 
      /usr/local/mysql/bin/mariadbd(_Z21mysql_execute_commandP3THDb+0x9d8c)[0xb39e7c]
      		 
      sql/sql_class.h:2830(THD::enter_stage(PSI_stage_info_v1 const*, char const*, char const*, unsigned int))[0xb24c79]
      		 
      /usr/local/mysql/bin/mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0x2cf8)[0xb1e648]
      		 
      sql/sql_parse.cc:1407(do_command(THD*, bool))[0xb25971]
      		 
      sql/sql_connect.cc:1416(do_handle_one_connection(CONNECT*, bool))[0xf0d066]
      		 
      sql/sql_connect.cc:1322(handle_one_connection)[0xf0caa9]
      		 
      perfschema/pfs.cc:2203(pfs_spawn_thread)[0x19d710b]
      		 
      nptl/pthread_create.c:478(start_thread)[0x7f1faba8e609]
      		 
      addr2line: DWARF error: section .debug_info is larger than its filesize! (0x93ef57 vs 0x530f28)
      		 
      /lib/x86_64-linux-gnu/libc.so.6(clone+0x43)[0x7f1fab7a6133]

      Attachments

        Issue Links

          is duplicated by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-36363 MariaDB crashes within JOIN optimization

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-28619 Server crash in /sql/sql_window.cc:3033 in Window_funcs_sort::setup(THD*, SQL_SELECT*, List_iterator<Item_window_func>&, st_join_table*)

          • Critical - Crashes, loss of data, severe memory leak.
          • Stalled

          Bug - A problem which impairs or prevents the functions of the product. MDEV-29681 Server crashes when optimizing SQL with ORDER BY

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            View 10 older comments
            psergei Sergei Petrunia added a comment -

            Ok, this patch updates select_lex->window_funcs.
            But there is also st_select_lex::add_window_spec() called which populates st_select_lex::window_specs and changes other members...
            Will we have to move those, too? (Please wait with coding this).

            psergei Sergei Petrunia added a comment - Ok, this patch updates select_lex->window_funcs . But there is also st_select_lex::add_window_spec() called which populates st_select_lex::window_specs and changes other members... Will we have to move those, too? (Please wait with coding this).
            psergei Sergei Petrunia added a comment -

            A suggestion considered in discussion with Sanja:

            Should we just delay the calls to
            st_select_lex::add_window_spec()
            st_select_lex::add_window_func()
            until e.g. window function's fix_fields() call?

            Possible issues here are:

            • fix_fields() is called on each statement execution
            • The above functions update st_select_lex::fields_in_window_functions. That member is used in st_select_lex::get_cardinality_of_ref_ptrs_slice(), which is called before fix_fields is called for Item_windowfunc objects.
            psergei Sergei Petrunia added a comment - A suggestion considered in discussion with Sanja: Should we just delay the calls to st_select_lex::add_window_spec() st_select_lex::add_window_func() until e.g. window function's fix_fields() call? Possible issues here are: fix_fields() is called on each statement execution The above functions update st_select_lex::fields_in_window_functions . That member is used in st_select_lex::get_cardinality_of_ref_ptrs_slice(), which is called before fix_fields is called for Item_windowfunc objects.
            psergei Sergei Petrunia added a comment - - edited

            The problem part of the grammar, with my suggestion in comments:

                    | query_expression_body_ext_parens
            		 
                      {
            		 
                        Lex->push_select(!$1->first_select()->next_select() ? 
                                           $1->first_select() : $1->fake_select_lex); 
                        // psergey: here, we could modify the context so that window functions
            		 
                        // are listed somewhere else than the current select.
            		 
                        // for example Select->parse_win_function_data_here .
            		 
                        // (Note that this will still work if query_expression_tail has subqueries)
            		 
                      }
            		 
                      query_expression_tail
            		 
                      {
            		 
                        // Inside this function, in Lex_order_limit_lock::set_to,  
                        // the data from Select->parse_win_function_data_here will be copied
            		 
                        // to the same select where ORDER BY clause is put.
            		 
                        if (!($$= Lex->add_tail_to_query_expression_body_ext_parens($1, $3)))
            		 
                           MYSQL_YYABORT;
            		 
             
            		 
                      }

            This still looks messy. Maybe, it's easier to walk the parse tree and collect info about window functions?
            Note that we will only have to walk the select list and order by. We won't need to walk into subqueries. We won't need to walk the WHERE clause, which can be large.

            psergei Sergei Petrunia added a comment - - edited The problem part of the grammar, with my suggestion in comments: | query_expression_body_ext_parens { Lex->push_select(!$1->first_select()->next_select() ? $1->first_select() : $1->fake_select_lex); // psergey: here, we could modify the context so that window functions // are listed somewhere else than the current select. // for example Select->parse_win_function_data_here . // (Note that this will still work if query_expression_tail has subqueries) } query_expression_tail { // Inside this function, in Lex_order_limit_lock::set_to, // the data from Select->parse_win_function_data_here will be copied // to the same select where ORDER BY clause is put. if (!($$= Lex->add_tail_to_query_expression_body_ext_parens($1, $3))) MYSQL_YYABORT;   } This still looks messy. Maybe, it's easier to walk the parse tree and collect info about window functions? Note that we will only have to walk the select list and order by. We won't need to walk into subqueries. We won't need to walk the WHERE clause, which can be large.
            psergei Sergei Petrunia added a comment -

            Final version of the fix suggestion:

            At the parser stage, Window Functions should not "register" themselves in st_select_lex::window_funcs and st_select_lex::window_specs.

            This should occur at a later stage, in JOIN::prepare, before the st_select_lex::get_cardinality_of_ref_ptrs_slice() call.

            Walk the SELECT's select list and order by clause and collect the contents of st_select_lex::window_funcs and st_select_lex::window_specs.

            psergei Sergei Petrunia added a comment - Final version of the fix suggestion: At the parser stage, Window Functions should not "register" themselves in st_select_lex::window_funcs and st_select_lex::window_specs. This should occur at a later stage, in JOIN::prepare, before the st_select_lex::get_cardinality_of_ref_ptrs_slice() call. Walk the SELECT's select list and order by clause and collect the contents of st_select_lex::window_funcs and st_select_lex::window_specs.
            ycp Yuchen Pei added a comment - - edited

            As per psergei, the runtime team has taken over this ticket.

            I think it makes sense, if the cause of the bug is the inconsistent attachments of Item_window_func to SELECT_LEX, resulted from actions during parsing / preparation.

            ycp Yuchen Pei added a comment - - edited As per psergei , the runtime team has taken over this ticket. I think it makes sense, if the cause of the bug is the inconsistent attachments of Item_window_func to SELECT_LEX, resulted from actions during parsing / preparation.

            People

              Unassigned Unassigned
              csfuzz csfuzz
              Votes:
              2 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

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