diff options
author | Dmitry Shulga <dmitry.shulga@mariadb.com> | 2022-01-19 11:15:22 +0700 |
---|---|---|
committer | Dmitry Shulga <dmitry.shulga@mariadb.com> | 2022-01-19 21:43:32 +0700 |
commit | 810ef9117a54f8dfbd362d959d46a2322f86a9d0 (patch) | |
tree | 501cf940238da19c33e7d6ecf42095f4cd9b4e30 /sql/sql_select.cc | |
parent | 9cd6ecfe501bcbee04d2d203baa81c927664c9e2 (diff) | |
download | mariadb-git-810ef9117a54f8dfbd362d959d46a2322f86a9d0.tar.gz |
MDEV-24827: MariaDB 10.5.5 crash (sig 11) during a SELECT
Running a query using cursor could lead to a server crash on
building a temporary table used for handling the query.
For example, the following cursor
DECLARE cur1 CURSOR FOR
SELECT t2.c1 AS c1 FROM t1 LEFT JOIN t2 ON t1.c1 = t2.c1
WHERE EXISTS (SELECT 1 FROM t1 WHERE c2 = -1) ORDER BY c1;
declared and executed inside a stored routine could result in server
crash on creating a temporary table used for handling the ORDER BY clause.
Crash occurred on attempt to create the temporary table's fields based
on fields whose data located in a memory root that already freed.
It happens inside the function return_zero_rows() where the method
Select_materialize::send_result_set_metadata() is invoked for cursor case.
This method calls the st_select_lex_unit::get_column_types() in order to
get a list of items with types of columns for the temporary table being created.
The method st_select_lex_unit::get_column_types() returns
first_select()->join->fields
in case it is invoked for a cursor. Unfortunately, this memory has been already
deallocated bit earlier by calling
join->join_free();
inside the function return_zero_rows().
In case the query listed in the example is run in conventional way (without
using cursor) the method st_select_lex_unit::get_column_types()
returns first_select()->item_list that is not touched by invocation
of the method join->join_free() so everything is fine for that.
So, to fix the issue the resources allocated for the JOIN class should be
released after any activities with the JOIN class has been completed,
that is as the last statement before returning from the function
return_zero_rows().
This patch includes tests both for the case when a cursor is run explicitly
from within a stored routine and for the case when a cursor is opened
implicitly as prescribed by the STMT_ATTR_CURSOR_TYPE attribute of
binary protocol (the case of prepared statement).
Diffstat (limited to 'sql/sql_select.cc')
-rw-r--r-- | sql/sql_select.cc | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/sql/sql_select.cc b/sql/sql_select.cc index a7e2ac4e374..abdc79c1bf3 100644 --- a/sql/sql_select.cc +++ b/sql/sql_select.cc @@ -12914,8 +12914,6 @@ return_zero_rows(JOIN *join, select_result *result, List<TABLE_LIST> &tables, DBUG_RETURN(0); } - join->join_free(); - if (send_row) { /* @@ -12962,6 +12960,8 @@ return_zero_rows(JOIN *join, select_result *result, List<TABLE_LIST> &tables, if (!send_error) result->send_eof(); // Should be safe } + join->join_free(); + DBUG_RETURN(0); } |