MySQL Bugs: #53103: MTR test ps crashes in optimize

Bug #53103	MTR test ps crashes in optimize_cond() when running with --debug
Submitted:	23 Apr 2010 9:34	Modified:	23 Nov 2010 3:24
Reporter:	Olav Sandstå	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Optimizer	Severity:	S3 (Non-critical)
Version:	6.0.14	OS:	Any
Assigned to:	Jørgen Løland	CPU Architecture:	Any
Tags:	materialization, optimizer_switch

Description:
When running the MTR test ps with --debug the MySQL server crashes due to calling a pure virtual member function of the Item class. 

The mysqld.1.err file contains:

Pure virtual function called
100423 10:05:50 - mysqld got signal 6 ;

The core file contains the following call stack:

=>[1] __pollsys(0x804580c, 0x2, 0x0, 0x0), at 0xfeaf1d15 
  [2] _pollsys(0x804580c, 0x2, 0x0, 0x0, 0x8045660, 0x94, 0x9320400, 0x3, 0x3, 0xcdfd5e8, 0x8da2630), at 0xfeade7a8 
  [3] poll(0x804580c, 0x2, 0xffffffff), at 0xfea97834 
  [4] handle_connections_sockets(), line 5599 in "mysqld.cc"
  [5] mysqld_main(argc = 48, argv = 0x934bd00), line 5072 in "mysqld.cc"
  [6] main(argc = 12, argv = 0x8045a10), line 24 in "main.cc"
current thread: t@2
=>[1] __sigtimedwait(0xfecbef90, 0xfecbedcc, 0x0, 0xfeade849), at 0xfeaf10c5 
  [2] sigtimedwait(0xfecbef90, 0x0, 0x0, 0xfeade9d7, 0x0), at 0xfeade905 
  [3] sigwait(0xfecbef90, 0xfeb70000, 0xfecbeeb4, 0xfeac872b), at 0xfeade9ed 
  [4] __posix_sigwait(0xfecbef90, 0xfecbef8c), at 0xfeac873c 
  [5] signal_hand(arg = (nil)), line 3083 in "mysqld.cc"
  [6] pfs_spawn_thread(arg = 0x93232b0), line 1012 in "pfs.cc"
  [7] _thrp_setup(0xfec70200), at 0xfeaecd66 
  [8] _lwp_start(0xfecbef90, 0xfecbedcc, 0x0, 0xfeade849, 0xfecbeddc, 0xfefd618d), at 0xfeaecff0 
current thread: t@4
  [1] _lwp_kill(0x4, 0x6, 0x0, 0xfeaea9fa), at 0xfeaf22a5 
  [2] thr_kill(0x4, 0x6), at 0xfeaeaa1c 
=>[3] my_write_core(sig = 6), line 328 in "stacktrace.c"
  [4] handle_segfault(sig = 6), line 2880 in "mysqld.cc"
  [5] __sighndlr(0x6, 0x0, 0xfec69420, 0x831e970), at 0xfeaed0cf 
  [6] call_user_handler(0x6), at 0xfeae01bf 
  [7] sigacthandler(0x6, 0x0, 0xfec69420, 0xf, 0x0, 0x807007), at 0xfeae03ef 
  ---- called from signal handler with signal 6 (SIGABRT) ------
  [8] _lwp_kill(0x4, 0x6, 0xfec6965c, 0xfea9ab7e), at 0xfeaf22a5 
  [9] raise(0x6, 0x6, 0xfec69694, 0xfea71f34), at 0xfea9ab8a 
  [10] abort(0xfec696e8), at 0xfea71f9c 
  [11] __Crun::pure_error(0xcf0d490, 0x0), at 0xfed57951 
  [12] Item_ref::print(this = 0xce37038, str = 0xfec69898, query_type = QT_ORDINARY), line 6436 in "item.cc"
  [13] Item_func::print_op(this = 0xce37138, str = 0xfec69898, query_type = QT_ORDINARY), line 448 in "item_func.cc"
  [14] Item_bool_func2::print(this = 0xce37138, str = 0xfec69898, query_type = QT_ORDINARY), line 367 in "item_cmpfunc.h"
  [15] Item_cond::print(this = 0xcdf9848, str = 0xfec69898, query_type = QT_ORDINARY), line 4446 in "item_cmpfunc.cc"
  [16] st_select_lex::print(this = 0xce35b48, thd = 0xcdd06f0, str = 0xfec69898, query_type = QT_ORDINARY), line 22868 in "sql_select.cc"
  [17] subselect_single_select_engine::print(this = 0xce376a8, str = 0xfec69898, query_type = QT_ORDINARY), line 2840 in "item_subselect.cc"
  [18] subselect_hash_sj_engine::print(this = 0xce37d00, str = 0xfec69898, query_type = QT_ORDINARY), line 3376 in "item_subselect.cc"
  [19] Item_subselect::print(this = 0xce375d8, str = 0xfec69898, query_type = QT_ORDINARY), line 396 in "item_subselect.cc"
  [20] Item_in_subselect::print(this = 0xce375d8, str = 0xfec69898, query_type = QT_ORDINARY), line 1794 in "item_subselect.cc"
  [21] Item_func::print_args(this = 0xce379e0, str = 0xfec69898, from = 0, query_type = QT_ORDINARY), line 438 in "item_func.cc"
  [22] Item_func::print(this = 0xce379e0, str = 0xfec69898, query_type = QT_ORDINARY), line 427 in "item_func.cc"
  [23] Item_cond::print(this = 0xcdf9900, str = 0xfec69898, query_type = QT_ORDINARY), line 4452 in "item_cmpfunc.cc"
  [24] print_where(cond = 0xcdf9900, info = 0x8dd729f "original", query_type = QT_ORDINARY), line 68 in "sql_test.cc"
  [25] optimize_cond(join = 0xcef32e8, conds = 0xcdf9900, join_list = 0xce3fe18, build_equalities = true, cond_value = 0xcef8024), line 13781 in "sql_select.cc"
  [26] JOIN::optimize(this = 0xcef32e8), line 1562 in "sql_select.cc"
  [27] mysql_select(thd = 0xcdd06f0, rref_pointer_array = 0xce3fe58, tables = 0xce40ad8, wild_num = 0, fields = CLASS, conds = 0xcdf9900, og_num = 0, order = (nil), group = (nil), having = (nil), proc_param = (nil), select_options = 2416184064ULL, result = 0xce376e0, unit = 0xce3f894, select_lex = 0xce3fd54), line 3229 in "sql_select.cc"
  [28] handle_select(thd = 0xcdd06f0, lex = 0xce3f838, result = 0xce376e0, setup_tables_done_option = 0), line 311 in "sql_select.cc"
  [29] execute_sqlcom_select(thd = 0xcdd06f0, all_tables = 0xce40ad8), line 5103 in "sql_parse.cc"
  [30] mysql_execute_command(thd = 0xcdd06f0), line 2358 in "sql_parse.cc"
  [31] Prepared_statement::execute(this = 0xce5e430, expanded_query = 0xfec6c4e0, open_cursor = false), line 3761 in "sql_prepare.cc"
  [32] Prepared_statement::execute_loop(this = 0xce5e430, expanded_query = 0xfec6c4e0, open_cursor = false, packet = (nil), packet_end = (nil)), line 3408 in "sql_prepare.cc"
  [33] mysql_sql_stmt_execute(thd = 0xcdd06f0), line 2599 in "sql_prepare.cc"
  [34] mysql_execute_command(thd = 0xcdd06f0), line 2368 in "sql_parse.cc"
  [35] mysql_parse(thd = 0xcdd06f0, inBuf = 0xcdf95a8 "EXECUTE STMT USING @id,@id", length = 26U, found_semicolon = 0xfec6ecec), line 6131 in "sql_parse.cc"
  [36] dispatch_command(command = COM_QUERY, thd = 0xcdd06f0, packet = 0xcd5b699 "EXECUTE STMT USING @id,@id", packet_length = 26U), line 1154 in "sql_parse.cc"
  [37] do_command(thd = 0xcdd06f0), line 838 in "sql_parse.cc"
  [38] do_handle_one_connection(thd_arg = 0xcdd06f0), line 1187 in "sql_connect.cc"
  [39] handle_one_connection(arg = 0xcdd06f0), line 1127 in "sql_connect.cc"
  [40] pfs_spawn_thread(arg = 0xcd691b0), line 1012 in "pfs.cc"
  [41] _thrp_setup(0xfec70a00), at 0xfeaecd66 
  [42] _lwp_start(0x4, 0x6, 0x0, 0xfeaea9fa, 0xfec692f8, 0x8fa9a44), at 0xfeaecff0 

It seems like it is during the second execution of the following prepared statement this crash happens (copied from mysql-test/t/ps.test):

PREPARE STMT FROM
"SELECT GROUP_CONCAT(Track SEPARATOR ', ') FROM t1
  WHERE Member_ID=? AND Action='Enrolled' AND
        (Track,Action_Date) IN (SELECT Track, MAX(Action_Date) FROM t1
                                  WHERE Member_ID=?
                                    GROUP BY Track 
                                      HAVING Track>='CAD' AND
                                             MAX(Action_Date)>'2006-03-01')";
SET @id='111111';
EXECUTE STMT USING @id,@id;
SET @id='222222';
EXECUTE STMT USING @id,@id;

How to repeat:
1. Branch the latest source code from mysql-6.0-codebase-bugfixing

2. Build debug binaries. I used the following commands for doing this:

    cmake . -DWITH_DEBUG=1 -DWITH_INNOBASE_STORAGE_ENGINE=1
    gmake

3. Run the test:

    cd mysql-test
    ./mtr --debug ps

Note that I used the Sun Studio compiler on Solaris 10 on an x86 machine when this happend but would expect it to happen on other platforms too.

Running the ps test with --debug on Linux also results in the same crash.

Running the test with Valgrind produces the following error report:

==20069== Thread 4:
==20069== Invalid read of size 8
==20069==    at 0x78EB94: Item_ref::print(String*, enum_query_type) (item.cc:643
6)
==20069==    by 0x7C7AF7: Item_func::print_op(String*, enum_query_type) (item_fu
nc.cc:448)
==20069==    by 0x7AE656: Item_bool_func2::print(String*, enum_query_type) (item
_cmpfunc.h:367)
==20069==    by 0x7A05A1: Item_cond::print(String*, enum_query_type) (item_cmpfu
nc.cc:4446)
==20069==    by 0x61B62E: st_select_lex::print(THD*, String*, enum_query_type) (
sql_select.cc:22868)
==20069==    by 0x7F06B2: subselect_single_select_engine::print(String*, enum_qu
ery_type) (item_subselect.cc:2840)
==20069==    by 0x7F038C: subselect_hash_sj_engine::print(String*, enum_query_ty
pe) (item_subselect.cc:3376)
==20069==    by 0x7F042D: Item_subselect::print(String*, enum_query_type) (item_
subselect.cc:396)
==20069==    by 0x7F05C6: Item_in_subselect::print(String*, enum_query_type) (it
em_subselect.cc:1794)
==20069==    by 0x7C6016: Item_func::print_args(String*, unsigned, enum_query_ty
pe) (item_func.cc:438)
==20069==    by 0x7C7C0D: Item_func::print(String*, enum_query_type) (item_func.
cc:427)
==20069==    by 0x7A05FE: Item_cond::print(String*, enum_query_type) (item_cmpfu
nc.cc:4452)
==20069==    by 0x686F59: print_where(Item*, char const*, enum_query_type) (sql_
test.cc:68)
==20069==    by 0x63C5C7: optimize_cond(JOIN*, Item*, List<TABLE_LIST>*, bool, I
tem::cond_result*) (sql_select.cc:13781)
==20069==    by 0x643E78: JOIN::optimize() (sql_select.cc:1562)
==20069==    by 0x649258: mysql_select(THD*, Item***, TABLE_LIST*, unsigned, Lis
t<Item>&, Item*, unsigned, st_order*, st_order*, Item*, st_order*, unsigned long
 long, select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:3229)
==20069==  Address 0x9AA5998 is 24 bytes inside a block of size 256 free'd
==20069==    at 0x4A0541E: free (vg_replace_malloc.c:233)
==20069==    by 0xA60C85: my_no_flags_free (my_malloc.c:66)
==20069==    by 0xA5613F: free_root (my_alloc.c:349)
==20069==    by 0x5F78D1: dispatch_command(enum_server_command, THD*, char*, uns
igned) (sql_parse.cc:1533)
==20069==    by 0x5F7B30: do_command(THD*) (sql_parse.cc:838)
==20069==    by 0x6D545F: do_handle_one_connection(THD*) (sql_connect.cc:1187)
==20069==    by 0x6D5524: handle_one_connection (sql_connect.cc:1127)
==20069==    by 0xA36127: pfs_spawn_thread(void*) (pfs.cc:1012)
==20069==    by 0x30242062F6: start_thread (in /lib64/libpthread-2.5.so)
==20069==    by 0x30236D1B6C: clone (in /lib64/libc-2.5.so)

Thank you for the bug report. Verified on FC 12 X86_64:

[miguel@tikal mysql-test]$ ./mtr --debug ps
Logging: ./mtr  --debug ps
100423  7:55:29 [Note] Buffered information: Performance schema disabled (reason: start parameters).

100423  7:55:29 [Note] Plugin 'FEDERATED' is disabled.
100423  7:55:29 [Note] Plugin 'ndbcluster' is disabled.
MySQL Version 6.0.14
Checking supported features...
 - using ndbcluster when necessary, mysqld supports it
 - SSL connections supported
 - binaries are debug compiled
Collecting tests...
vardir: /home/miguel/bzr/6.0-codebase/mysql-test/var
Removing old var directory...
Creating var directory '/home/miguel/bzr/6.0-codebase/mysql-test/var'...
Installing system database...
Using server port 59728

==============================================================================

TEST                                      RESULT   TIME (ms)
------------------------------------------------------------

worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 13000..13009
main.ps                                  [ fail ]
        Test ended at 2010-04-23 07:55:42

CURRENT_TEST: main.ps
mysqltest: At line 1058: query 'EXECUTE STMT USING @id,@id' failed: 2013: Lost connection to MySQL server during query

The result from queries just before the failure was:

Verified just as described on 32-bit Ubuntu 8.04 (not a cmake build, just usual BUILD/compile-pentium-debug-max script was used):

openxs@ubuntu:/home2/openxs/dbs/6.0-bugfixing/mysql-test$ ./mtr --debug ps
Logging: ./mtr  --debug ps
100423 13:55:36 [Note] Buffered information: Performance schema disabled (reason: start parameters).

100423 13:55:36 [Note] Plugin 'FEDERATED' is disabled.
100423 13:55:36 [Note] Plugin 'ndbcluster' is disabled.
MySQL Version 6.0.14
Checking supported features...
 - using ndbcluster when necessary, mysqld supports it
 - SSL connections supported
 - binaries are debug compiled
Collecting tests...
vardir: /home2/openxs/dbs/6.0-bugfixing/mysql-test/var
Checking leftover processes...
Removing old var directory...
Creating var directory '/home2/openxs/dbs/6.0-bugfixing/mysql-test/var'...
Installing system database...
Using server port 52563
worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 13000..13009

==============================================================================

TEST                                      RESULT   TIME (ms)
------------------------------------------------------------

main.ps                                  [ fail ]
        Test ended at 2010-04-23 13:56:04

CURRENT_TEST: main.ps
mysqltest: At line 1058: query 'EXECUTE STMT USING @id,@id' failed: 2013: Lost connection to MySQL server during query

The result from queries just before the failure was:
< snip >
('444444', 'Enrolled', '2006-03-01', 'CAD' ),
('555555', 'Disenrolled', '2006-03-01', 'CAD' ),
('555555', 'Enrolled', '2006-07-21', 'CAD' ),
('555555', 'Disenrolled', '2006-03-01', 'CHF' ),
('666666', 'Enrolled', '2006-02-09', 'CAD' ),
('666666', 'Enrolled', '2006-05-12', 'CHF' ),
('666666', 'Disenrolled', '2006-06-01', 'CAD' );
PREPARE STMT FROM
"SELECT GROUP_CONCAT(Track SEPARATOR ', ') FROM t1
  WHERE Member_ID=? AND Action='Enrolled' AND
        (Track,Action_Date) IN (SELECT Track, MAX(Action_Date) FROM t1
                                  WHERE Member_ID=?
                                    GROUP BY Track 
                                      HAVING Track>='CAD' AND
                                             MAX(Action_Date)>'2006-03-01')";
SET @id='111111';
EXECUTE STMT USING @id,@id;
GROUP_CONCAT(Track SEPARATOR ', ')
NULL
SET @id='222222';

More results from queries before failure can be found in /home2/openxs/dbs/6.0-bugfixing/mysql-test/var/log/ps.log

Server [mysqld.1 - pid: 9990, winpid: 9990, exit: 256] failed during test run
Server log from this test:
100423 13:55:43 [Note] Buffered information: Performance schema enabled.

100423 13:55:43 [Note] Plugin 'FEDERATED' is disabled.
100423 13:55:43 [Note] Plugin 'InnoDB' is disabled.
100423 13:55:43 [Note] Plugin 'ndbcluster' is disabled.
100423 13:55:44 [Note] Event Scheduler: Loaded 0 events
100423 13:55:44 [Note] /home2/openxs/dbs/6.0-bugfixing/libexec/mysqld: ready for connections.
Version: '6.0.14-alpha-debug-log'  socket: '/home2/openxs/dbs/6.0-bugfixing/mysql-test/var/tmp/mysqld.1.sock'  port: 13000  Source distribution
100423 13:55:59 - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=1048576
read_buffer_size=131072
max_used_connections=2
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 60134 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x9145408
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0xb3471f60 thread_stack 0x30c00
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(my_print_stacktrace+0x32) [0x87c109d]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(handle_segfault+0x2f2) [0x8310138]
[0xb7713420]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(Item_func::print_op(String*, enum_query_type)+0x63) [0x82649bb]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(Item_bool_func2::print(String*, enum_query_type)+0x1f) [0x828a96f]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(Item_cond::print(String*, enum_query_type)+0x75) [0x827d521]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(st_select_lex::print(THD*, String*, enum_query_type)+0x52c) [0x83a21d0]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(subselect_single_select_engine::print(String*, enum_query_type)+0x2c) [0x82b9ef4]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(subselect_hash_sj_engine::print(String*, enum_query_type)+0x47) [0x82b9ba1]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(Item_subselect::print(String*, enum_query_type)+0x49) [0x82b9c47]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(Item_in_subselect::print(String*, enum_query_type)+0x93) [0x82b9e0b]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(Item_func::print_args(String*, unsigned int, enum_query_type)+0x67) [0x8262e85]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(Item_func::print(String*, enum_query_type)+0x5d) [0x8264ad7]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(Item_cond::print(String*, enum_query_type)+0xe2) [0x827d58e]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(print_where(Item*, char const*, enum_query_type)+0x9a) [0x83fe8de]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld [0x83b9a3b]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(JOIN::optimize()+0x3a2) [0x83c8adc]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*)+0x283) [0x83cd5a5]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(handle_select(THD*, LEX*, select_result*, unsigned long)+0x1ec) [0x83d316a]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld [0x83224d9]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(mysql_execute_command(THD*)+0xa7a) [0x83243b8]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(Prepared_statement::execute(String*, bool)+0x468) [0x83e68de]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(Prepared_statement::execute_loop(String*, bool, unsigned char*, unsigned char*)+0xf7) [0x83ea547]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(mysql_sql_stmt_execute(THD*)+0x180) [0x83ea7de]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(mysql_execute_command(THD*)+0xaa9) [0x83243e7]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(mysql_parse(THD*, char const*, unsigned int, char const**)+0x229) [0x832cec7]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x9e9) [0x832da45]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(do_command(THD*)+0x241) [0x832efa5]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(do_handle_one_connection(THD*)+0x150) [0x831b31c]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(handle_one_connection+0x25) [0x831b3db]
/home2/openxs/dbs/6.0-bugfixing/libexec/mysqld(pfs_spawn_thread(void*)+0xb8) [0x8857686]
/lib/tls/i686/cmov/libpthread.so.0 [0xb76e84fb]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e) [0xb74f7e5e]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x915af58 = SELECT GROUP_CONCAT(Track SEPARATOR ', ') FROM t1
  WHERE Member_ID='222222' AND Action='Enrolled' AND
        (Track,Action_Date) IN (SELECT Track, MAX(Action_Date) FROM t1
                                  WHERE Member_ID='222222'
                                    GROUP BY Track 
                                      HAVING Track>='CAD' AND
                                             MAX(Action_Date)>'2006-03-01')
thd->thread_id=2
thd->killed=NOT_KILLED

smaller testcase: run this with --debug:

CREATE TABLE t1(Track varchar(15));

INSERT INTO t1 VALUES ('CAD'), ('CAD');

PREPARE STMT FROM
"SELECT 1 FROM t1
  WHERE
        Track IN (SELECT Track FROM t1
                                    GROUP BY Track 
                                      HAVING Track>='CAD')";
EXECUTE STMT ;
EXECUTE STMT ;

DEALLOCATE PREPARE STMT;
DROP TABLE t1;

goes away with materialization=off (subquery mat, not semijoin mat)

as this is not a genuine regression, I go back to BKA-with-semijoin bugs as planned.

The problem is that JOIN::prepare is not called for the subquery on second execution of the PS. Because the subquery is not reprepared, the Item_ref for 'Track' in the having clause refers to a temporary Item_field created by change_to_use_tmp_fields() during JOIN::exec of the first PS execution. This temporary Item_field is now invalid.

The suggested fix is to prepare the subquery on all PS executions so that the fields are resolved. For subselect_single_select_engine, this is done in prepare(). 

In this bug, hash_sj_engine is used, and it seems like it was designed to reuse subselect_single_select_engine::prepare():

From item_subselect.h:
class subselect_hash_sj_engine: public subselect_uniquesubquery_engine
...
  /*
    The old engine already chosen at parse time and stored in permanent memory.
    Through this member we can re-create and re-prepare materialize_join for
    each execution of a prepared statement. We akso resuse the functionality
    of subselect_single_select_engine::[prepare | cols].
  */
...
however, prepare() is not reused in the implementation, which reads:
int prepare() { return 0; }

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/110614

3188 Jorgen Loland	2010-06-09
      BUG#53103 - MTR test ps crashes in optimize_cond() when 
                  running with --debug
      
      The problem was that when subselect_hash_sj_engine was used to 
      materialize a subselect, the subselect was not prepared for 
      each execution of a PS. Because of this, Items in the subselect
      were not fixed on the second execution of the PS.
      
      The fix is to call materialize_engine->prepare() in 
      subselect_hash_sj_engine::prepare() method. From comments 
      in the class, this seems to have been the intention all along.
     @ mysql-test/r/subselect_sj_debug.result
        Add test for BUG#53103
     @ mysql-test/t/subselect_sj_debug.test
        Add test for BUG#53103
     @ sql/item_subselect.h
        Make subselect_hash_sj_engine::prepare() reuse subselect_single_select_engine::prepare() so that the subselect gets reprepared on each PS execution.

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/110968

3193 Jorgen Loland	2010-06-14
      BUG#53103 - MTR test ps crashes in optimize_cond() when 
                  running with --debug
      
      The problem was that when subselect_hash_sj_engine was used to 
      materialize a subselect, the subselect was not prepared for 
      each execution of a PS. Because of this, Items in the subselect
      were not fixed on the second execution of the PS.
      
      The fix is to call materialize_engine->prepare() in 
      subselect_hash_sj_engine::prepare() method. From comments 
      in the class, this seems to have been the intention all along.
     @ mysql-test/r/subselect_sj2.result
        Add test for BUG#53103
     @ mysql-test/t/subselect_sj2.test
        Add test for BUG#53103
     @ sql/item_subselect.h
        Make subselect_hash_sj_engine::prepare() reuse subselect_single_select_engine::prepare() so that the subselect gets reprepared on each PS execution.

Pushed to opt-backporting

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/110977

3196 Jorgen Loland	2010-06-14
      BUG#53103 - MTR test ps crashes in optimize_cond() when 
                  running with --debug
      
      Move test from subselect_sj2 to subselect4.
     @ mysql-test/r/subselect4.result
        Move test from subselect_sj2 to subselect4.
     @ mysql-test/r/subselect_sj2.result
        Move test from subselect_sj2 to subselect4.
     @ mysql-test/t/subselect4.test
        Move test from subselect_sj2 to subselect4.
     @ mysql-test/t/subselect_sj2.test
        Move test from subselect_sj2 to subselect4.

Pushed into mysql-next-mr (revid:alik@sun.com-20100816062819-bluwgdq8q4xysmlg) (version source revid:alik@sun.com-20100816062612-enatdwnv809iw3s9) (pib:20)

Pushed into mysql-trunk 5.6.99-m5 (revid:alexander.nozdrin@oracle.com-20101113155825-czmva9kg4n31anmu) (version source revid:vasil.dimov@oracle.com-20100629074804-359l9m9gniauxr94) (merge vers: 5.6.99-m4) (pib:21)

Bug does not appear in any released 5.6.x version. No 5.6.1 changelog entry needed.