Test case for bug lp:1001117, MySQL BUG#12330344

Analysis:
The problem in the original MySQL bug is that the range optimizer
performs its analysis in a separate MEM_ROOT object that is freed
after the range optimzier is done. During range analysis get_mm_tree
calls Item_func_like::select_optimize, which in turn evaluates its
right argument. In the test case the right argument is a subquery.

In MySQL, subqueries are optimized lazyly, thus the call to val_str
triggers optimization for the subquery. All objects needed by the
subquery plan end up in the temporary MEM_ROOT used by the range
optimizer. When execution ends, the JOIN::cleanup process tries to
cleanup objects of the subquery plan, but all these objects are gone
with the temporary MEM_ROOT. The solution for MySQL is to switch the
mem_root.

In MariaDB with the patch for bug lp:944706, all constant subqueries
that may be used by the optimization process are preoptimized. Therefore
Item_func_like::select_optimize only triggers subquery execution, and
the above problem is not present.

The patch however adds a test whether the evaluated right argument of
the LIKE predicate is expensive. This is consistent with our approach
not to evaluate expensive expressions during optimization.

1 files changed, 13 insertions, 0 deletions

diff --git a/mysql-test/t/partition.test b/mysql-test/t/partition.test
index d6d49c59255..08c028c8224 100644
--- a/mysql-test/t/partition.test
+++ b/mysql-test/t/partition.test
@@ -2463,3 +2463,16 @@ INSERT INTO t1 VALUES (6,8,10);
 SELECT 1 FROM t1 JOIN t1 AS t2 USING (a);
 
 drop table t1;
+
+--echo #
+--echo # LP BUG#1001117 Crash on a simple select that uses a temptable view
+--echo # MySQL Bug #12330344 Crash and/or valgrind errors in free_io_cache with join, view,
+--echo # partitioned table
+--echo #
+
+CREATE TABLE t1(a INT PRIMARY KEY) PARTITION BY LINEAR KEY (a);
+CREATE ALGORITHM=TEMPTABLE VIEW vtmp AS
+SELECT 1 FROM t1 AS t1_0 JOIN t1 ON t1_0.a LIKE (SELECT 1 FROM t1);
+SELECT * FROM vtmp;
+DROP VIEW vtmp;
+DROP TABLE t1;