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

Server crashes in st_select_lex::collect_grouping_fields_for_derived

Details

    Description

      create view v1 AS select database() union values (1),(2);
      		 
      select 1 from v1 where make_set(1, `database()`);

      Both debug and non-debug versions are affected.

      10.4 a50ce9445844c0bdcf8a

      		 
      Version: '10.4.15-MariaDB-debug-log'  
      [ERROR] mysqld got signal 11 ;
      		 
       
      		 
      Server version: 10.4.15-MariaDB-debug-log
      		 
       
      		 
      sql/sql_lex.cc:7915(st_select_lex::collect_grouping_fields_for_derived(THD*, st_order*))[0x55fd3ce4d6a1]
      		 
      sql/sql_derived.cc:1478(pushdown_cond_for_derived(THD*, Item*, TABLE_LIST*))[0x55fd3cfcc23d]
      		 
      sql/sql_select.cc:2098(JOIN::optimize_inner())[0x55fd3cfc6d68]
      		 
      sql/sql_select.cc:1615(JOIN::optimize())[0x55fd3cfe74cf]
      		 
      sql/sql_select.cc:4681(mysql_select(THD*, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0x55fd3cfb94be]
      		 
      sql/sql_select.cc:410(handle_select(THD*, LEX*, select_result*, unsigned long))[0x55fd3cf2d42b]
      		 
      sql/sql_parse.cc:6355(execute_sqlcom_select(THD*, TABLE_LIST*))[0x55fd3cf1ad85]
      		 
      sql/sql_parse.cc:3889(mysql_execute_command(THD*))[0x55fd3cf364f5]
      		 
      sql/sql_parse.cc:7896(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x55fd3cf0daf0]
      		 
      sql/sql_parse.cc:1837(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x55fd3cf0a56f]
      		 
      sql/sql_parse.cc:1352(do_command(THD*))[0x55fd3d2e7141]
      		 
      sql/sql_connect.cc:1412(do_handle_one_connection(CONNECT*))[0x55fd3d2e69e3]
      		 
      sql/sql_connect.cc:1317(handle_one_connection)[0x55fd3e915cf1]
      		 
      nptl/pthread_create.c:487(start_thread)[0x7f03bcdbbfa3]
      		 
      x86_64/clone.S:97(clone)[0x7f03bc3c24cf]
      		 
       
      		 
      Query (0x62b000062290): select 1 from v1 where make_set(1, `database()`)

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-20224 main.derived crashes with ASAN with error use-after-poison

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            varun Varun Gupta (Inactive) added a comment -

            Another test case:

            CREATE VIEW v1 AS SELECT 3 as a UNION VALUES (1),(2);
            		 
            ANALYZE FORMAT=JSON SELECT * from v1 WHERE a=3;
            		 
            SELECT * from v1 WHERE a=3;

            varun Varun Gupta (Inactive) added a comment - Another test case: CREATE VIEW v1 AS SELECT 3 as a UNION VALUES (1),(2); ANALYZE FORMAT=JSON SELECT * from v1 WHERE a=3; SELECT * from v1 WHERE a=3;
            varun Varun Gupta (Inactive) added a comment -

            Patch
            http://lists.askmonty.org/pipermail/commits/2020-October/014346.html

            varun Varun Gupta (Inactive) added a comment - Patch http://lists.askmonty.org/pipermail/commits/2020-October/014346.html
            igor Igor Babaev added a comment - - edited

            The problem appeared after the loss of the lines

                if (!sl->cond_pushdown_is_allowed())
            		 
                  continue;

            after the commit 

            commit d3ff133390231d8224843995af6b11f6a381803e
            		 
            Author: Galina Shalygina <galina.shalygina@mariadb.com>
            		 
            Date:   Tue May 15 23:45:59 2018 +0200
            		 
                MDEV-12387 Push conditions into materialized subqueries

            I don't think it was an intentional loss.
            I would recommend to add the test case to 10.3 rather than to 10.4 to avoid another loss of those lines.

            igor Igor Babaev added a comment - - edited The problem appeared after the loss of the lines if (!sl->cond_pushdown_is_allowed()) continue; after the commit commit d3ff133390231d8224843995af6b11f6a381803e Author: Galina Shalygina <galina.shalygina@mariadb.com> Date: Tue May 15 23:45:59 2018 +0200 MDEV-12387 Push conditions into materialized subqueries I don't think it was an intentional loss. I would recommend to add the test case to 10.3 rather than to 10.4 to avoid another loss of those lines.
            monty Michael Widenius added a comment -

            I agree with Igor.

            Push the test case to 10.3 and the fix to 10.4.

            A small suggestion for the patch:

            + if (!sl->cond_pushdown_is_allowed())
            + continue;
            Item *extracted_cond_copy;

            Move the if() after "Item *extracted_cond_copy"
            Two reasons for this:

            • Then we have identical code in 10.3 and 10.4
            • It's better to have first all variable declarations and then the code (to keep declarations and code separated)
            monty Michael Widenius added a comment - I agree with Igor. Push the test case to 10.3 and the fix to 10.4. A small suggestion for the patch: + if (!sl->cond_pushdown_is_allowed()) + continue; Item *extracted_cond_copy; Move the if() after "Item *extracted_cond_copy" Two reasons for this: Then we have identical code in 10.3 and 10.4 It's better to have first all variable declarations and then the code (to keep declarations and code separated)

            People

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