Bug #58561 Server Crash with correlated subquery and MyISAM tables when semijoin=on
Submitted: 29 Nov 2010 14:22 Modified: 20 Jan 2011 19:19
Reporter: SaiKumar V Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Optimizer Severity:S1 (Critical)
Version:mysql-next-mr-opt-backporting OS:Linux (Rqd Hat x86)
Assigned to: Roy Lyseng CPU Architecture:Any
Tags: optimizer_switch, semijoin

[29 Nov 2010 14:22] SaiKumar V
Description:
The tables are all MyISAM tables in the query. The query is also a correlated sub-query.

note:- if the tables are InnoDB, the bug is not noticed.

mysql> set optimizer_switch='semijoin=off';
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT col_int_key  
    -> FROM B GRANDPARENT1  
    -> WHERE ( col_int_key  , col_int_nokey  )  IN (  
    -> SELECT PARENT1 .pk  , PARENT1 .pk  
    -> FROM BB PARENT1  JOIN CC PARENT2  ON PARENT2 .col_varchar_key  = PARENT2 .col_varchar_key
    -> WHERE GRANDPARENT1 .col_varchar_key  IN (  
    -> SELECT col_varchar_key  
    -> FROM C  )  AND PARENT1 .pk  = GRANDPARENT1 .col_int_key  
    -> ORDER  BY PARENT1 .col_date_key  )   ;
Empty set (0.00 sec)

mysql> set optimizer_switch='semijoin=on';
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT col_int_key   FROM B GRANDPARENT1   WHERE ( col_int_key  , col_int_nokey  )  IN (   SELECT PARENT1 .pk  , PARENT1 .pk   FROM BB PARENT1  JOIN CC PARENT2  ON PARENT2 .col_varchar_key  = PARENT2 .col_varchar_key WHERE GRANDPARENT1 .col_varchar_key  IN (   SELECT col_varchar_key   FROM C  )  AND PARENT1 .pk  = GRANDPARENT1 .col_int_key   ORDER  BY PARENT1 .col_date_key  );
ERROR 2013 (HY000): Lost connection to MySQL server during query

How to repeat:
Bug found in:-
mysql-next-mr-opt-backporting
revno: 3259

This is a RQG failure, found when seed was set to time (seed=time).
The Optimizer settings used for RQG test runs are as below:
SET GLOBAL OPTIMIZER_SWITCH = 'semijoin=on';
SET GLOBAL optimizer_join_cache_level = 4
--------------------------------------------------------------------------

Steps to Repro:-

CREATE TABLE CC (
  pk int(11) NOT NULL AUTO_INCREMENT,
  col_int_nokey int(11) DEFAULT NULL,
  col_int_key int(11) DEFAULT NULL,
  col_date_key date DEFAULT NULL,
  col_varchar_key varchar(1) DEFAULT NULL,
  PRIMARY KEY (pk),
  KEY col_int_key (col_int_key),
  KEY col_date_key (col_date_key),
  KEY col_varchar_key (col_varchar_key,col_int_key)
) ENGINE=MyISAM AUTO_INCREMENT=30 DEFAULT CHARSET=latin1;
INSERT INTO CC VALUES (10,7,8,NULL,'v');
INSERT INTO CC VALUES (11,1,9,'2006-06-14','r');
INSERT INTO CC VALUES (12,5,9,'2002-09-12','a');
INSERT INTO CC VALUES (13,3,186,'2005-02-15','m');
INSERT INTO CC VALUES (14,6,NULL,NULL,'y');
INSERT INTO CC VALUES (15,92,2,'2008-11-04','j');
INSERT INTO CC VALUES (16,7,3,'2004-09-04','d');
INSERT INTO CC VALUES (17,NULL,0,'2006-06-05','z');
INSERT INTO CC VALUES (18,3,133,'1900-01-01','e');
INSERT INTO CC VALUES (19,5,1,'1900-01-01','h');
INSERT INTO CC VALUES (20,1,8,'1900-01-01','b');
INSERT INTO CC VALUES (21,2,5,'2005-01-13','s');
INSERT INTO CC VALUES (22,NULL,5,'2006-05-21','e');
INSERT INTO CC VALUES (23,1,8,'2003-09-08','j');
INSERT INTO CC VALUES (24,0,6,'2006-12-23','e');
INSERT INTO CC VALUES (25,210,51,'2006-10-15','f');
INSERT INTO CC VALUES (26,8,4,'2005-04-06','v');
INSERT INTO CC VALUES (27,7,7,'2008-04-07','x');
INSERT INTO CC VALUES (28,5,6,'2006-10-10','m');
INSERT INTO CC VALUES (29,NULL,4,'1900-01-01','c');
CREATE TABLE BB (
  pk int(11) NOT NULL AUTO_INCREMENT,
  col_int_nokey int(11) DEFAULT NULL,
  col_int_key int(11) DEFAULT NULL,
  col_date_key date DEFAULT NULL,
  col_varchar_key varchar(1) DEFAULT NULL,
  PRIMARY KEY (pk),
  KEY col_int_key (col_int_key),
  KEY col_date_key (col_date_key),
  KEY col_varchar_key (col_varchar_key,col_int_key)
) ENGINE=MyISAM AUTO_INCREMENT=11 DEFAULT CHARSET=latin1;
INSERT INTO BB VALUES (10,8,8,'2002-02-21',NULL);
CREATE TABLE C (
  pk int(11) NOT NULL AUTO_INCREMENT,
  col_int_nokey int(11) DEFAULT NULL,
  col_int_key int(11) DEFAULT NULL,
  col_date_key date DEFAULT NULL,
  col_varchar_key varchar(1) DEFAULT NULL,
  PRIMARY KEY (pk),
  KEY col_int_key (col_int_key),
  KEY col_date_key (col_date_key),
  KEY col_varchar_key (col_varchar_key,col_int_key)
) ENGINE=MyISAM AUTO_INCREMENT=21 DEFAULT CHARSET=latin1;
INSERT INTO C VALUES (1,NULL,2,NULL,'w');
INSERT INTO C VALUES (2,7,9,'2001-09-19','m');
INSERT INTO C VALUES (3,9,3,'2004-09-12','m');
INSERT INTO C VALUES (4,7,9,NULL,'k');
INSERT INTO C VALUES (5,4,NULL,'2002-07-19','r');
INSERT INTO C VALUES (6,2,9,'2002-12-16','t');
INSERT INTO C VALUES (7,6,3,'2006-02-08','j');
INSERT INTO C VALUES (8,8,8,'2006-08-28','u');
INSERT INTO C VALUES (9,NULL,8,'2001-04-14','h');
INSERT INTO C VALUES (10,5,53,'2000-01-05','o');
INSERT INTO C VALUES (11,NULL,0,'2003-12-06',NULL);
INSERT INTO C VALUES (12,6,5,'1900-01-01','k');
INSERT INTO C VALUES (13,188,166,'2002-11-27','e');
INSERT INTO C VALUES (14,2,3,NULL,'n');
INSERT INTO C VALUES (15,1,0,'2003-05-27','t');
INSERT INTO C VALUES (16,1,1,'2005-05-03','c');
INSERT INTO C VALUES (17,0,9,'2001-04-18','m');
INSERT INTO C VALUES (18,9,5,'2005-12-27','y');
INSERT INTO C VALUES (19,NULL,6,'2004-08-20','f');
INSERT INTO C VALUES (20,4,2,'1900-01-01','d');
CREATE TABLE B (
  pk int(11) NOT NULL AUTO_INCREMENT,
  col_int_nokey int(11) DEFAULT NULL,
  col_int_key int(11) DEFAULT NULL,
  col_date_key date DEFAULT NULL,
  col_varchar_key varchar(1) DEFAULT NULL,
  PRIMARY KEY (pk),
  KEY col_int_key (col_int_key),
  KEY col_date_key (col_date_key),
  KEY col_varchar_key (col_varchar_key,col_int_key)
) ENGINE=MyISAM AUTO_INCREMENT=2 DEFAULT CHARSET=latin1;
INSERT INTO B VALUES (1,1,7,'1900-01-01','f');

 
SELECT col_int_key FROM B GRANDPARENT1  WHERE ( col_int_key , col_int_key )  IN (  SELECT PARENT1 .pk ,  PARENT1 .pk FROM BB PARENT1  JOIN CC PARENT2  ON PARENT2 .col_varchar_key = PARENT2 .col_varchar_key WHERE GRANDPARENT1 .col_varchar_key  IN (  SELECT col_varchar_key  FROM C  )  AND PARENT1 .pk  = GRANDPARENT1 .col_int_key  ORDER  BY PARENT1 .col_date_key  )   ;
[30 Nov 2010 13:18] SaiKumar V
This is crash trace observed is as below:-

Program terminated with signal 11, Segmentation fault.
#0  0x00948410 in __kernel_vsyscall ()
#0  0x00948410 in __kernel_vsyscall ()
#1  0x00819047 in pthread_kill () from /lib/libpthread.so.0
#2  0x086e7993 in my_write_core (sig=11) at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/mysys/stacktrace.c:330
#3  0x08162a89 in handle_segfault (sig=11) at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/mysqld.cc:2507
#4  <signal handler called>
#5  0x08238d70 in make_join_statistics (join=0x96a97e8, tables_arg=0x96a7378, conds=0x96d6f78, keyuse_array=0x96a997c)
    at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/sql_select.cc:4844
#6  0x0823c45b in JOIN::optimize (this=0x96a97e8) at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/sql_select.cc:1949
#7  0x083ddc01 in subselect_single_select_engine::exec (this=0x96a9380)
    at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/item_subselect.cc:2325
#8  0x083de680 in Item_subselect::exec (this=0x96a92b8) at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/item_subselect.cc:311
#9  0x083e2945 in Item_in_subselect::exec (this=0x96a92b8) at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/item_subselect.cc:427
#10 0x083da9f4 in Item_in_subselect::val_bool (this=0x96a92b8) at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/item_subselect.cc:1023
#11 0x08175f58 in Item::val_bool_result (this=0x96a92b8) at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/item.h:868
#12 0x0837dbb0 in Item_in_optimizer::val_int (this=0x96a9f00) at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/item_cmpfunc.cc:1947
#13 0x08239eda in make_join_select (join=0x96a9428, cond=0x96a9f00) at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/sql_select.cc:9481
#14 0x0823cb50 in JOIN::optimize (this=0x96a9428) at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/sql_select.cc:2044
#15 0x0823ff3b in mysql_select (thd=0x95ff478, rref_pointer_array=0x9600cb8, tables=0x96a6658, wild_num=0, fields=@0x9600c48, conds=0x96a92b8, og_num=0, 
    order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x96a9418, unit=0x960076c, select_lex=0x9600bb4)
    at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/sql_select.cc:3482
#16 0x08245b72 in handle_select (thd=0x95ff478, lex=0x9600708, result=0x96a9418, setup_tables_done_option=0)
    at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/sql_select.cc:322
#17 0x081e9cc0 in execute_sqlcom_select (thd=0x95ff478, all_tables=0x96a6658)
    at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/sql_parse.cc:4494
#18 0x081ead59 in mysql_execute_command (thd=0x95ff478) at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/sql_parse.cc:2092
#19 0x081f23ec in mysql_parse (thd=0x95ff478, 
    rawbuf=0x96a6248 "SELECT col_int_key FROM B GRANDPARENT1  WHERE ( col_int_key , col_int_key )  IN (  SELECT PARENT1 .pk ,  PARENT1 .pk FROM BB PARENT1  JOIN CC PARENT2  ON PARENT2 .col_varchar_key = PARENT2 .col_varcha"..., length=364, parser_state=0xb1e70110)
    at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/sql_parse.cc:5537
#20 0x081f3536 in dispatch_command (command=COM_QUERY, thd=0x95ff478, 
    packet=0x969e219 "SELECT col_int_key FROM B GRANDPARENT1  WHERE ( col_int_key , col_int_key )  IN (  SELECT PARENT1 .pk ,  PARENT1 .pk FROM BB PARENT1  JOIN CC PARENT2  ON PARENT2 .col_varchar_key = PARENT2 .col_varcha"..., packet_length=367)
    at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/sql_parse.cc:1056
#21 0x081f4810 in do_command (thd=0x95ff478) at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/sql_parse.cc:796
#22 0x082c130b in do_handle_one_connection (thd_arg=0x95ff478) at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/sql_connect.cc:745
#23 0x082c1403 in handle_one_connection (arg=0x95ff478) at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/sql/sql_connect.cc:684
#24 0x085723c1 in pfs_spawn_thread (arg=0x9685b08) at /export/home2/tmp/sai/new/mysql-next-mr-opt-backporting/storage/perfschema/pfs.cc:1078
#25 0x0081443b in start_thread () from /lib/libpthread.so.0
#26 0x0076bfde in clone () from /lib/libc.so.6

Additional details:-
The bug was found on branch mysql-next-mr-opt-backporting
and revision-id :- tor.didriksen@oracle.com-20101116165843-86cs5woahaule77b

The RQG Grammar used here was :- subquery_semijoin_nested.yy
and the seed value is seed=1290598434
[1 Dec 2010 6:15] SaiKumar V
cleaned up the trace to further:-

Program terminated with signal 11, Segmentation fault.
#0  0x00948410 in __kernel_vsyscall ()
#0  0x00948410 in __kernel_vsyscall ()
#1  0x00819047 in pthread_kill () from /lib/libpthread.so.0
#2  0x086e7993 in my_write_core (sig=11) at mysys/stacktrace.c:330
#3  0x08162a89 in handle_segfault (sig=11) at sql/mysqld.cc:2507
#4  <signal handler called>
#5  0x08238d70 in make_join_statistics (join=0x96a97e8, tables_arg=0x96a7378, conds=0x96d6f78, keyuse_array=0x96a997c) at sql/sql_select.cc:4844
#6  0x0823c45b in JOIN::optimize (this=0x96a97e8) at sql/sql_select.cc:1949
#7  0x083ddc01 in subselect_single_select_engine::exec (this=0x96a9380) at sql/item_subselect.cc:2325
#8  0x083de680 in Item_subselect::exec (this=0x96a92b8) at sql/item_subselect.cc:311
#9  0x083e2945 in Item_in_subselect::exec (this=0x96a92b8) at sql/item_subselect.cc:427
#10 0x083da9f4 in Item_in_subselect::val_bool (this=0x96a92b8) at sql/item_subselect.cc:1023
#11 0x08175f58 in Item::val_bool_result (this=0x96a92b8) at sql/item.h:868
#12 0x0837dbb0 in Item_in_optimizer::val_int (this=0x96a9f00) at sql/item_cmpfunc.cc:1947
#13 0x08239eda in make_join_select (join=0x96a9428, cond=0x96a9f00) at sql/sql_select.cc:9481
#14 0x0823cb50 in JOIN::optimize (this=0x96a9428) at sql/sql_select.cc:2044
#15 0x0823ff3b in mysql_select (thd=0x95ff478, rref_pointer_array=0x9600cb8,tables=0x96a6658, wild_num=0, fields=@0x9600c48, conds=0x96a92b8, og_num=0,    order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608,result=0x96a9418, unit=0x960076c, select_lex=0x9600bb4) at sql/sql_select.cc:3482
#16 0x08245b72 in handle_select (thd=0x95ff478, lex=0x9600708, result=0x96a9418,setup_tables_done_option=0) at sql/sql_select.cc:322
#17 0x081e9cc0 in execute_sqlcom_select (thd=0x95ff478, all_tables=0x96a6658) at sql/sql_parse.cc:4494
#18 0x081ead59 in mysql_execute_command (thd=0x95ff478) at sql/sql_parse.cc:2092
#19 0x081f23ec in mysql_parse (thd=0x95ff478,  rawbuf=0x96a6248 "SELECT col_int_key FROM B GRANDPARENT1  WHERE ( col_int_key ,col_int_key )  IN (  SELECT PARENT1 .pk ,  PARENT1 .pk FROM BB PARENT1  JOIN CC PARENT2 ON PARENT2 .col_varchar_key = PARENT2 .col_varcha"..., length=364, parser_state=0xb1e70110) at sql/sql_parse.cc:5537
#20 0x081f3536 in dispatch_command (command=COM_QUERY, thd=0x95ff478, packet=0x969e219 "SELECT col_int_key FROM B GRANDPARENT1  WHERE ( col_int_key ,
col_int_key )  IN (  SELECT PARENT1 .pk ,  PARENT1 .pk FROM BB PARENT1  JOIN CC PARENT2 ON PARENT2 .col_varchar_key = PARENT2 .col_varcha"..., packet_length=367) at sql/sql_parse.cc:1056
#21 0x081f4810 in do_command (thd=0x95ff478) at sql/sql_parse.cc:796
#22 0x082c130b in do_handle_one_connection (thd_arg=0x95ff478) at sql/sql_connect.cc:745
#23 0x082c1403 in handle_one_connection (arg=0x95ff478) at sql/sql_connect.cc:684
#24 0x085723c1 in pfs_spawn_thread (arg=0x9685b08) at storage/perfschema/pfs.cc:1078
#25 0x0081443b in start_thread () from /lib/libpthread.so.0
#26 0x0076bfde in clone () from /lib/libc.so.6
[22 Dec 2010 14:03] Roy Lyseng
This problem seems to have the same root cause as one of the problems described in
WL5561. When the test case is run through code from that branch, the result is correct.

The root cause is still not identified, though.
[12 Jan 2011 15:33] Roy Lyseng
It turned out that WL5561 just hid the real problem. Patch is coming soon...
[12 Jan 2011 15:39] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/128531

3322 Roy Lyseng	2011-01-12
      Bug#58561: Server Crash with correlated subquery and MyISAM tables
                 when semijoin=on
      
      The problem here is that the variable 'sargables' contains invalid data
      after call to update_ref_and_keys(), causing a segmentation fault.
      Further inspection showed that the number of conditions was calculated
      erroneously, and it was also noticed that it was because
      thd->lex->current_select was not equal to select_lex passed as argument.
      The culprit was found to be subselect_single_select_engine::exec()
      that did not restore the value of 'current_select' after an engine
      was changed.
      
      Problem is fixed by restoring current_select properly.
      We also clean up the code slightly by replacing
      thd->lex->current_select in update_ref_and_keys()
      with the passed select_lex argument.
      
      mysql-test/include/subquery.inc
        Added test case for bug#58561.
      
      mysql-test/r/subquery_all.result
      mysql-test/r/subquery_all_jcl6.result
      mysql-test/r/subquery_nomat_nosj.result
      mysql-test/r/subquery_nomat_nosj_jcl6.result
      mysql-test/r/subquery_none.result
      mysql-test/r/subquery_none_jcl6.result
        Added test results for bug#58561.
      
      sql/item_subselect.cc
        In subselect_single_select_engine::exec(), restored saved
        'current_select' when an engine is changed.
      
      sql/sql_select.cc
        In update_ref_and_keys(), replaced reference to
        thd->lex->current_select with the select_lex passed as argument.
        This is a code cleanup fix.
[12 Jan 2011 16:12] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/128542

3322 Roy Lyseng	2011-01-12
      Bug#58561: Server Crash with correlated subquery and MyISAM tables
                 when semijoin=on
      
      The problem here is that the variable 'sargables' contains invalid data
      after call to update_ref_and_keys(), causing a segmentation fault.
      Further inspection showed that the number of conditions was calculated
      erroneously, and it was also noticed that it was because
      thd->lex->current_select was not equal to select_lex passed as argument.
      The culprit was found to be subselect_single_select_engine::exec()
      that did not restore the value of 'current_select' after an engine
      was changed.
      
      Problem is fixed by restoring current_select properly.
      We also clean up the code slightly by replacing
      thd->lex->current_select in update_ref_and_keys()
      with the passed select_lex argument.
      
      mysql-test/include/subquery.inc
        Added test case for bug#58561.
      
      mysql-test/r/subquery_all.result
      mysql-test/r/subquery_all_jcl6.result
      mysql-test/r/subquery_nomat_nosj.result
      mysql-test/r/subquery_nomat_nosj_jcl6.result
      mysql-test/r/subquery_none.result
      mysql-test/r/subquery_none_jcl6.result
        Added test results for bug#58561.
      
      sql/item_subselect.cc
        In subselect_single_select_engine::exec(), restored saved
        'current_select' when an engine is changed.
        Implemented 'clean exit' policy as a code cleanup fix.
      
      sql/sql_select.cc
        In update_ref_and_keys(), replaced reference to
        thd->lex->current_select with the select_lex passed as argument.
        This is a code cleanup fix.
[13 Jan 2011 8:48] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/128598

3322 Roy Lyseng	2011-01-13
      Bug#58561: Server Crash with correlated subquery and MyISAM tables
                 when semijoin=on
      
      The problem here is that the variable 'sargables' contains invalid data
      after call to update_ref_and_keys(), causing a segmentation fault.
      Further inspection showed that the number of conditions was calculated
      erroneously, and it was also noticed that it was because
      thd->lex->current_select was not equal to select_lex passed as argument.
      The culprit was found to be subselect_single_select_engine::exec()
      that did not restore the value of 'current_select' after an engine
      was changed.
      
      Problem is fixed by restoring current_select properly.
      We also clean up the code slightly by replacing
      thd->lex->current_select in update_ref_and_keys()
      with the passed select_lex argument.
      
      mysql-test/include/subquery.inc
        Added test case for bug#58561.
      
      mysql-test/r/subquery_all.result
      mysql-test/r/subquery_all_jcl6.result
      mysql-test/r/subquery_nomat_nosj.result
      mysql-test/r/subquery_nomat_nosj_jcl6.result
      mysql-test/r/subquery_none.result
      mysql-test/r/subquery_none_jcl6.result
        Added test results for bug#58561.
      
      sql/item_subselect.cc
        In subselect_single_select_engine::exec(), restored saved
        'current_select' when an engine is changed.
        Implemented 'clean exit' policy as a code cleanup fix.
      
      sql/sql_select.cc
        In update_ref_and_keys(), replaced reference to
        thd->lex->current_select with the select_lex passed as argument.
        This is a code cleanup fix.
[20 Jan 2011 9:10] Bugs System
Pushed into mysql-trunk 5.6.2 (revid:jorgen.loland@oracle.com-20110120090926-xms6k8scdrtl8yai) (version source revid:jorgen.loland@oracle.com-20110120090926-xms6k8scdrtl8yai) (merge vers: 5.6.2) (pib:24)
[20 Jan 2011 19:19] Paul DuBois
Noted in 5.6.2 changelog.

With semi-join optimization enabled, queries with a correlated
subquery on MyISAM tables could cause a server crash.
[8 Apr 2011 14:52] Paul DuBois
Correction. Bug does not affect 5.6.x users. No changelog entry needed.