Bug #2266 Crash if stored procedure containing subquery, after INSERT

• Submitted: 3 Jan 2004 7:59
• Modified: 31 May 2004 11:27
• Reporter: Peter Gulutzan
• Status: Closed
• Category: MySQL Server
• Severity: S3 (Non-critical)
• Version: MySQL 5.0.0
• OS: Linux (SuSE 8.2)
• Assigned to: Oleksandr Byelkin
• CPU Architecture: Any

[3 Jan 2004 7:59] Peter Gulutzan

Description:
A SELECT containing a subquery, inside a stored procedure, is okay if there are no rows in 
the table. But mysqld crashes after I INSERT a row into the table. 

How to repeat:
mysql> create procedure p22 () select (select s1 from t22) from t22; 
Query OK, 0 rows affected (0.00 sec) 
 
mysql> create table t22 (s1 int); 
Query OK, 0 rows affected (0.32 sec) 
 
mysql> call p22(); 
Empty set (0.00 sec) 
 
Query OK, 0 rows affected (0.00 sec) 
 
mysql> insert into t22 values (1); 
Query OK, 1 row affected (0.00 sec) 
 
mysql> call p22(); 
ERROR 2013 (HY000): Lost connection to MySQL server during query

[13 Jan 2004 3:39] Per-Erik Martin

The problem is that the member variable 'join' is set
to 'new JOIN(...)' in subselect_single_select_engine::prepare()
at the first call, and then reused; but the join the is allocated
in the caller's mem_root which is freed after each call.

The solution is to write a cleanup() method when this cset (hf's)
is pushed.

[20 May 2004 1:08] Oleksandr Byelkin

ChangeSet 
  1.1683 04/05/20 02:02:49 [e-mail] +22 -0 
  PS and SP made compatible in mechanism used for preparing query for 
rexecutions (Bug #2266)

[31 May 2004 11:27] Oleksandr Byelkin

Thank you for bugreport. This bug is fixed, patch is pushed in our internal 
repository and will be present in next server release.