Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MCOL-4043 Fix memory leaks - 1 (second attempt) #1297

Merged

Conversation

tntnatbry
Copy link
Contributor

simpleScalarFilterToParseTree() performs a dynamic allocation
of a ParseTree object, but this memory is never freed later.
We now keep track of this allocation and perform the delete
in ~CSEP/CSEP::unserialize() after the query finishes.

simpleScalarFilterToParseTree() performs a dynamic allocation
of a ParseTree object, but this memory is never freed later.
We now keep track of this allocation and perform the delete
in ~CSEP/CSEP::unserialize() after the query finishes.
@tntnatbry
Copy link
Contributor Author

Below are the queries triggering various code paths to simpleScalarFilterToParseTree() that lead to a leak fixed by this patch:

drop table if exists cs1;
create table cs1 (a int)engine=columnstore;
insert into cs1 values (123);
select * from cs1 where a=(select a from cs1);
select * from cs1 having a=(select a from cs1);
select * from cs1 where a=(select a from cs1) and a!=(select a from cs1);
select * from cs1 where a=(select a from cs1) or a!=(select a from cs1);
select * from (select * from cs1 where a=(select a from cs1)) aa;
select * from cs1 aa where exists (select * from cs1 bb where bb.a=(select a from cs1));
select * from cs1 aa where exists (select * from cs1 bb where aa.a=bb.a and bb.a=(select a from cs1));

@pleblanc1976 pleblanc1976 merged commit 5a0b877 into mariadb-corporation:develop-1.4 Jun 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants