[MDEV-2626] LP:1001117 - Crash on a simple select that uses a temptable view Created: 2012-05-18  Updated: 2014-06-20  Resolved: 2012-10-04

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Igor Babaev Assignee: Timour Katchaounov (Inactive)
Resolution: Fixed Votes: 0
Labels: Launchpad

Attachments: XML File LPexportBug1001117.xml    

 Description   

The following test case causes a crash of the server in MariaDB 5.5:

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;

(see also bug #12330344 from mysql code line)

 Comments   
Comment by Igor Babaev [ 2012-05-18 ]

Re: Crash on a simple select that uses a temptable view
I failed to reproduce the crash on MariaDB 5.2/5.3.

Comment by Sergei Petrunia [ 2012-05-18 ]

Re: Crash on a simple select that uses a temptable view
The bug shows two problems:

1. [As mentioned in the original bug] Subquery is evaluated while thd->mem_root is pointing to range optimizer's temporary MEM_ROOT

2. Subquery is evaluated by the optimizer. We've had a goal of this not happening, apparently there are still cases where it does happen.

Comment by Sergei Petrunia [ 2012-05-18 ]

Re: Crash on a simple select that uses a temptable view
Results of discussion with Timour:

1. Backport the original fix.
2. Also, make this: let Item_func_like::select_optimize() evaluate its right argument only if it's constant AND not expensive.

Comment by Sergei Petrunia [ 2012-05-18 ]

Re: Crash on a simple select that uses a temptable view
The fix has interesting interplay with fix for BUG#944706, will need to discuss with Timour again.

Comment by Sergei Petrunia [ 2012-05-23 ]

Re: Crash on a simple select that uses a temptable view
As discussed, re-assigning to Timour, because testscase also shows problem with his fix for constant subqueries.

Comment by Timour Katchaounov (Inactive) [ 2012-05-23 ]

Re: Crash on a simple select that uses a temptable view
The fix for bug lp:944706 (MDEV-193) makes the fix by MySQL unnecessary.
The reason is that the patch for lp:944706 pre-optimizes all constant
subqueries. Therefore, the subquery in test case is optimized in the
thread MEM_ROOT, and all its related data structures are there. Thus
deleting works fine. Item_func_like::select_optimize only executes the
subquery, which is fine too.

Unlike MariaDB, MySQL still has lazy optimization. As a result, when
Item_func_like::select_optimize executes the subquery, it also optimizes
the subquery just before execution. Naturally, this happens in the wrong
MEM_ROOT which is deleted after we exit the range optimizer. When the
recursive JOIN cleanup tries to delete optimizer-related class members
of the subquery, this memory is already gone, hence we get a crash.

So with respect to this specific bug, there is nothing to fix.
I will add an is_expensive() guard + the test case to the tree with the lp:944706 fix.
I will not add MySQL's patch, as it is not needed.

Comment by Rasmus Johansson (Inactive) [ 2012-05-24 ]

Launchpad bug id: 1001117

Generated at Thu Feb 08 06:43:07 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.