Commit d56f5dae authored by unknown's avatar unknown

Fix bug lp:1001506

This is a backport of the (unchaged) fix for MySQL bug #11764372, 57197.

Analysis:

When the outer query finishes its main execution and computes GROUP BY,
it needs to construct a new temporary table (and a corresponding JOIN) to
execute the last DISTINCT operation. At this point JOIN::exec calls
JOIN::join_free, which calls JOIN::cleanup -> TMP_TABLE_PARAM::cleanup
for both the outer and the inner JOINs. The call to the inner
TMP_TABLE_PARAM::cleanup sets copy_field = NULL, but not copy_field_end.

The final execution phase that computes the DISTINCT invokes:
evaluate_join_record -> end_write -> copy_funcs
The last function copies the results of all functions into the temp table.
copy_funcs walks over all functions in join->tmp_table_param.items_to_copy.
In this case items_to_copy contains both assignments to user variables.
The process of copying user variables invokes Item_func_set_user_var::check
which in turn re-evaluates the arguments of the user variable assignment.
This in turn triggers re-evaluation of the subquery, and ultimately
copy_field.

However, the previous call to TMP_TABLE_PARAM::cleanup for the subquery
already set copy_field to NULL but not its copy_field_end. This results
in a null pointer access, and a crash.

Fix:
Set copy_field_end and save_copy_field_end to null when deleting
copy fields in TMP_TABLE_PARAM::cleanup().
parent 950abd52
...@@ -456,4 +456,11 @@ SELECT (@v:=a) <> (@v:=1) FROM t1; ...@@ -456,4 +456,11 @@ SELECT (@v:=a) <> (@v:=1) FROM t1;
(@v:=a) <> (@v:=1) (@v:=a) <> (@v:=1)
1 1
DROP TABLE t1; DROP TABLE t1;
CREATE TABLE t1(a int);
INSERT INTO t1 VALUES (1), (2);
SELECT DISTINCT @a:=MIN(t1.a) FROM t1, t1 AS t2
GROUP BY @b:=(SELECT COUNT(*) > t2.a);
@a:=MIN(t1.a)
1
DROP TABLE t1;
End of 5.1 tests End of 5.1 tests
...@@ -365,4 +365,15 @@ SELECT (@v:=a) <> (@v:=1) FROM t1; ...@@ -365,4 +365,15 @@ SELECT (@v:=a) <> (@v:=1) FROM t1;
DROP TABLE t1; DROP TABLE t1;
#
# LP BUG#1001506 Crash on a query with GROUP BY and user variables
# MySQL Bug #11764372 57197: EVEN MORE USER VARIABLE CRASHING FUN
#
CREATE TABLE t1(a int);
INSERT INTO t1 VALUES (1), (2);
SELECT DISTINCT @a:=MIN(t1.a) FROM t1, t1 AS t2
GROUP BY @b:=(SELECT COUNT(*) > t2.a);
DROP TABLE t1;
--echo End of 5.1 tests --echo End of 5.1 tests
...@@ -2880,7 +2880,8 @@ public: ...@@ -2880,7 +2880,8 @@ public:
if (copy_field) /* Fix for Intel compiler */ if (copy_field) /* Fix for Intel compiler */
{ {
delete [] copy_field; delete [] copy_field;
save_copy_field= copy_field= 0; save_copy_field= copy_field= NULL;
save_copy_field_end= copy_field_end= NULL;
} }
} }
}; };
......
...@@ -16072,6 +16072,8 @@ copy_fields(TMP_TABLE_PARAM *param) ...@@ -16072,6 +16072,8 @@ copy_fields(TMP_TABLE_PARAM *param)
Copy_field *ptr=param->copy_field; Copy_field *ptr=param->copy_field;
Copy_field *end=param->copy_field_end; Copy_field *end=param->copy_field_end;
DBUG_ASSERT((ptr != NULL && end >= ptr) || (ptr == NULL && end == NULL));
for (; ptr != end; ptr++) for (; ptr != end; ptr++)
(*ptr->do_copy)(ptr); (*ptr->do_copy)(ptr);
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment