[MDEV-18015] Assertion `global_status_var.global_memory_used == 0' failed when using window functions and views Created: 2018-12-14  Updated: 2019-06-05  Resolved: 2019-06-05

Status: Closed
Project: MariaDB Server
Component/s: Optimizer - Window functions
Affects Version/s: 10.2, 10.3, 10.4
Fix Version/s: 10.2.25, 10.3.16, 10.4.6

Type: Bug Priority: Major
Reporter: Varun Gupta (Inactive) Assignee: Varun Gupta (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-15837 Assertion `item1->type() == Item::FIE... Closed

 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.



 Comments   
Comment by Varun Gupta (Inactive) [ 2018-12-14 ]

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)

Comment by Varun Gupta (Inactive) [ 2018-12-15 ]

Patch
http://lists.askmonty.org/pipermail/commits/2018-December/013208.html

Comment by Varun Gupta (Inactive) [ 2018-12-18 ]

Review suggestions provided by psergey

Comment by Varun Gupta (Inactive) [ 2018-12-19 ]

Patch
http://lists.askmonty.org/pipermail/commits/2018-December/013221.html

Comment by Varun Gupta (Inactive) [ 2019-05-01 ]

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;

Comment by Varun Gupta (Inactive) [ 2019-05-01 ]

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;

Comment by Varun Gupta (Inactive) [ 2019-05-13 ]

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.

Comment by Varun Gupta (Inactive) [ 2019-05-13 ]

Patch
http://lists.askmonty.org/pipermail/commits/2019-May/013764.html

Comment by Igor Babaev [ 2019-05-29 ]

Ok to push into 10.2

Generated at Thu Feb 08 08:40:51 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.