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

SIGSEGV in Item_field::fix_fields when using LEAD...OVER

Details

    Description

      On second select, server crashes.

      Attachments

        Issue Links

          is caused by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-25631 Crash executing query with VIEW, aggregate and subquery

          • Major - Major loss of function.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-31296 Crash in Item_func::fix_fields when prepared statement with subqueries and window function is executed with sql_mode = ONLY_FULL_GROUP_BY

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

          Activity

            Ascending order - Click to sort in descending order
            View 13 older comments
            danblack Daniel Black added a comment -

            10.6-fdc582fd983206ef9da531cc3e617fbf4db324d6

            		 
            Thread 19 "mysqld" received signal SIGSEGV, Segmentation fault.
            		 
            [Switching to Thread 0x7f8c4451d640 (LWP 152304)]
            		 
            0x0000000000d31d3c in Item_field::fix_fields (this=0x7f8ba003eab0, thd=0x7f8ba0000dc8, reference=0x7f8ba003eec8) at /home/dan/repos/mariadb-server-10.6/sql/item.cc:6117
            		 
            6117	        thd->lex == select->parent_lex &&
            		 
            (gdb) bt
            		 
            #0  0x0000000000d31d3c in Item_field::fix_fields (this=0x7f8ba003eab0, thd=0x7f8ba0000dc8, reference=0x7f8ba003eec8) at /home/dan/repos/mariadb-server-10.6/sql/item.cc:6117
            		 
            ...>
            		 
             
            		 
            (gdb) info locals
            		 
            table_list = 0x7f8ba003cc18
            		 
            from_field = 0x7f8ba0037af8
            		 
            outer_fixed = false
            		 
            select = 0x0
            		 
            (gdb) list
            		 
            6112	        goto mark_non_agg_field;
            		 
            6113	    }
            		 
            6114	
            6115	    if (!thd->lex->current_select->no_wrap_view_item &&
            		 
            6116	        thd->lex->in_sum_func &&
            		 
            6117	        thd->lex == select->parent_lex &&
            		 
            6118	        thd->lex->in_sum_func->nest_level == 
            6119	        select->nest_level)
            		 
            6120	      set_if_bigger(thd->lex->in_sum_func->max_arg_level,
            		 
            6121	                    select->nest_level);
            		 
             
            		 
            (gdb) p *context
            		 
            $3 = {<Sql_alloc> = {<No data fields>}, outer_context = 0x0, table_list = 0x0, first_name_resolution_table = 0x7f8ba003cc18, last_name_resolution_table = 0x7f8ba003cc18, natural_join_first_table = 0x0, select_lex = 0x0, error_processor = 0xd41f40 <dummy_error_processor(THD*, void*)>, error_processor_data = 0x0, resolve_in_select_list = false, ignored_tables = 0x0, security_ctx = 0x0}

            select is context->select_lex.

            danblack Daniel Black added a comment - 10.6-fdc582fd983206ef9da531cc3e617fbf4db324d6 Thread 19 "mysqld" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f8c4451d640 (LWP 152304)] 0x0000000000d31d3c in Item_field::fix_fields (this=0x7f8ba003eab0, thd=0x7f8ba0000dc8, reference=0x7f8ba003eec8) at /home/dan/repos/mariadb-server-10.6/sql/item.cc:6117 6117 thd->lex == select->parent_lex && (gdb) bt #0 0x0000000000d31d3c in Item_field::fix_fields (this=0x7f8ba003eab0, thd=0x7f8ba0000dc8, reference=0x7f8ba003eec8) at /home/dan/repos/mariadb-server-10.6/sql/item.cc:6117 ...>   (gdb) info locals table_list = 0x7f8ba003cc18 from_field = 0x7f8ba0037af8 outer_fixed = false select = 0x0 (gdb) list 6112 goto mark_non_agg_field; 6113 } 6114 6115 if (!thd->lex->current_select->no_wrap_view_item && 6116 thd->lex->in_sum_func && 6117 thd->lex == select->parent_lex && 6118 thd->lex->in_sum_func->nest_level == 6119 select->nest_level) 6120 set_if_bigger(thd->lex->in_sum_func->max_arg_level, 6121 select->nest_level);   (gdb) p *context $3 = {<Sql_alloc> = {<No data fields>}, outer_context = 0x0, table_list = 0x0, first_name_resolution_table = 0x7f8ba003cc18, last_name_resolution_table = 0x7f8ba003cc18, natural_join_first_table = 0x0, select_lex = 0x0, error_processor = 0xd41f40 <dummy_error_processor(THD*, void*)>, error_processor_data = 0x0, resolve_in_select_list = false, ignored_tables = 0x0, security_ctx = 0x0} select is context->select_lex .
            danblack Daniel Black added a comment -

            shulga, can you please review https://github.com/MariaDB/server/pull/2350.

            Removing MDEV-29731 as related as despite stack similarities the values in the stack are quite different.

            danblack Daniel Black added a comment - shulga , can you please review https://github.com/MariaDB/server/pull/2350 . Removing MDEV-29731 as related as despite stack similarities the values in the stack are quite different.
            vk4ypb Peter Bennett added a comment - - edited

            Thaks Daniel for taking a look at this and providing a fix. I have looked at the code change to item.cc and have manually applied this to my local 10.11 copy and tested my system and all good!!! Thanks heaps.

            I presume that this now goes through some sort of QA process. What would be the normal timeframe for this to get through to the main code release?

            Peter.

            vk4ypb Peter Bennett added a comment - - edited Thaks Daniel for taking a look at this and providing a fix. I have looked at the code change to item.cc and have manually applied this to my local 10.11 copy and tested my system and all good!!! Thanks heaps. I presume that this now goes through some sort of QA process. What would be the normal timeframe for this to get through to the main code release? Peter.
            danblack Daniel Black added a comment -

            Thanks for testing vk4ypb. I did test your original case attached here so I was pretty comfortable with it. Thanks for the nag.

            I'm hoping shulga is available to review this within ~1 week otherwise find another reviewer. As you see its quite a simple fix.

            The next scheduled release is 2023-04-27, however if there's an out of bound release (maybe MDEV-29988), I'll ask to have this included too.

            danblack Daniel Black added a comment - Thanks for testing vk4ypb . I did test your original case attached here so I was pretty comfortable with it. Thanks for the nag. I'm hoping shulga is available to review this within ~1 week otherwise find another reviewer. As you see its quite a simple fix. The next scheduled release is 2023-04-27, however if there's an out of bound release (maybe MDEV-29988 ), I'll ask to have this included too.
            shulga Dmitry Shulga added a comment -

            The patch looks good for me

            shulga Dmitry Shulga added a comment - The patch looks good for me

            People

              danblack Daniel Black
              vk4ypb Peter Bennett
              Votes:
              1 Vote for this issue
              Watchers:
              8 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.