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

Assertion `global_status_var.global_memory_used == 0' failed when using window functions and views

Details

    Description

      The mtr test case is:

      --source include/have_udf.inc
      CREATE FUNCTION myfunc_int RETURNS INTEGER SONAME "udf_example.so";
      create table t1(a int , b int);
      insert into t1 values(100, 54), (200, 199);
      create view v1 as select myfunc_int(max(a) over (order by 1) , b) from t1;
      select * from v1;
      

      Warnings are generated on shutdown.

      Attachments

        Issue Links

          Activity

            Here is the stack trace when i run the test with Valgrind

            Attempting backtrace. You can use the following information to find out
            ==30029== 16 bytes in 1 blocks are definitely lost in loss record 1 of 29
            ==30029==    at 0x4C280F3: malloc (vg_replace_malloc.c:299)
            ==30029==    by 0x114A3EA: my_malloc (my_malloc.c:101)
            ==30029==    by 0x7C4991: String::real_alloc(unsigned long) (sql_string.cc:47)
            ==30029==    by 0x6EB4AA: String::String(unsigned int) (sql_string.h:148)
            ==30029==    by 0x9D50E0: Cached_item_str::Cached_item_str(THD*, Item*) (item_buff.cc:76)
            ==30029==    by 0x9D4EE0: new_Cached_item(THD*, Item*, bool) (item_buff.cc:50)
            ==30029==    by 0x8E616F: Group_bound_tracker::Group_bound_tracker(THD*, SQL_I_List<st_order>*) (item_windowfunc.h:21)
            ==30029==    by 0x8E7BD9: Frame_range_current_row_bottom::Frame_range_current_row_bottom(THD*, SQL_I_List<st_order>*, SQL_I_List<st_order>*) (sql_window.cc:1367)
            ==30029==    by 0x8E39BF: get_frame_cursor(THD*, Window_spec*, bool) (sql_window.cc:2223)
            ==30029==    by 0x8E4ABA: get_window_functions_required_cursors(THD*, List<Item_window_func>&, List<Cursor_manager>*) (sql_window.cc:2475)
            ==30029==    by 0x8E550C: Window_func_runner::exec(THD*, TABLE*, SORT_INFO*) (sql_window.cc:2736)
            ==30029==    by 0x8E5650: Window_funcs_sort::exec(JOIN*, bool) (sql_window.cc:2767)
            ==30029==    by 0x8E5B4E: Window_funcs_computation::exec(JOIN*, bool) (sql_window.cc:2893)
            ==30029==    by 0x78DC02: AGGR_OP::end_send() (sql_select.cc:26668)
            ==30029==    by 0x778ABD: sub_select_postjoin_aggr(JOIN*, st_join_table*, bool) (sql_select.cc:18477)
            ==30029==    by 0x778DE7: sub_select(JOIN*, st_join_table*, bool) (sql_select.cc:18713)
            

            varun Varun Gupta (Inactive) added a comment - Here is the stack trace when i run the test with Valgrind Attempting backtrace. You can use the following information to find out ==30029== 16 bytes in 1 blocks are definitely lost in loss record 1 of 29 ==30029== at 0x4C280F3: malloc (vg_replace_malloc.c:299) ==30029== by 0x114A3EA: my_malloc (my_malloc.c:101) ==30029== by 0x7C4991: String::real_alloc(unsigned long) (sql_string.cc:47) ==30029== by 0x6EB4AA: String::String(unsigned int) (sql_string.h:148) ==30029== by 0x9D50E0: Cached_item_str::Cached_item_str(THD*, Item*) (item_buff.cc:76) ==30029== by 0x9D4EE0: new_Cached_item(THD*, Item*, bool) (item_buff.cc:50) ==30029== by 0x8E616F: Group_bound_tracker::Group_bound_tracker(THD*, SQL_I_List<st_order>*) (item_windowfunc.h:21) ==30029== by 0x8E7BD9: Frame_range_current_row_bottom::Frame_range_current_row_bottom(THD*, SQL_I_List<st_order>*, SQL_I_List<st_order>*) (sql_window.cc:1367) ==30029== by 0x8E39BF: get_frame_cursor(THD*, Window_spec*, bool) (sql_window.cc:2223) ==30029== by 0x8E4ABA: get_window_functions_required_cursors(THD*, List<Item_window_func>&, List<Cursor_manager>*) (sql_window.cc:2475) ==30029== by 0x8E550C: Window_func_runner::exec(THD*, TABLE*, SORT_INFO*) (sql_window.cc:2736) ==30029== by 0x8E5650: Window_funcs_sort::exec(JOIN*, bool) (sql_window.cc:2767) ==30029== by 0x8E5B4E: Window_funcs_computation::exec(JOIN*, bool) (sql_window.cc:2893) ==30029== by 0x78DC02: AGGR_OP::end_send() (sql_select.cc:26668) ==30029== by 0x778ABD: sub_select_postjoin_aggr(JOIN*, st_join_table*, bool) (sql_select.cc:18477) ==30029== by 0x778DE7: sub_select(JOIN*, st_join_table*, bool) (sql_select.cc:18713)
            varun Varun Gupta (Inactive) added a comment - Patch http://lists.askmonty.org/pipermail/commits/2018-December/013208.html
            varun Varun Gupta (Inactive) added a comment - - edited

            Review suggestions provided by psergey

            varun Varun Gupta (Inactive) added a comment - - edited Review suggestions provided by psergey
            varun Varun Gupta (Inactive) added a comment - Patch http://lists.askmonty.org/pipermail/commits/2018-December/013221.html

            A test case not involving UDF's

            create table t1 (id int, n1 int);
            insert into t1 values (1,1),(2,1),(3,2),(4,4);
            select max(n1) over (partition by 'abc') from t1;
            

            varun Varun Gupta (Inactive) added a comment - A test case not involving UDF's create table t1 (id int, n1 int); insert into t1 values (1,1),(2,1),(3,2),(4,4); select max(n1) over (partition by 'abc') from t1;

            Also check this test case, pointed by alice in MDEV-15837

            create table t1 (a int, b int);
            insert into t1 values (1,3), (2,2), (3,1), (1,3), (2,2), (3,1);
            select  lag(a) over (order by null desc), sum(a) over (order by null) from t1;
            

            varun Varun Gupta (Inactive) added a comment - Also check this test case, pointed by alice in MDEV-15837 create table t1 (a int, b int); insert into t1 values (1,3), (2,2), (3,1), (1,3), (2,2), (3,1); select lag(a) over (order by null desc), sum(a) over (order by null) from t1;

            The issue here is that we are not freeing the GROUP_BOUND_TRACKER for window functions, the group_bound_tracker is used mostly for partition by clause, also used by order by clause of window function
            for the case when we have RANK, DENSE_RANK etc.

            varun Varun Gupta (Inactive) added a comment - The issue here is that we are not freeing the GROUP_BOUND_TRACKER for window functions, the group_bound_tracker is used mostly for partition by clause, also used by order by clause of window function for the case when we have RANK, DENSE_RANK etc.
            varun Varun Gupta (Inactive) added a comment - Patch http://lists.askmonty.org/pipermail/commits/2019-May/013764.html

            Ok to push into 10.2

            igor Igor Babaev (Inactive) added a comment - Ok to push into 10.2

            People

              varun Varun Gupta (Inactive)
              varun Varun Gupta (Inactive)
              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.