subselect4.test fails in current 5.3

[Sergey Petrunia]

subselect4.test fails as follows:

worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
main.subselect4 [ fail ]
        Test ended at 2011-10-27 12:30:20

CURRENT_TEST: main.subselect4
mysqltest: At line 1755: query 'SELECT * FROM (SELECT t1.* FROM t1, t2 ) AS alias1 JOIN t3 ON ( t3.a = alias1.b )' failed: 2013: Lost connection to MySQL server during query

stack trace:
#0 0xb7fa4430 in __kernel_vsyscall ()
#0 0xb7fa4430 in __kernel_vsyscall ()
#1 0xb7f011c8 in pthread_kill () from /lib/tls/i686/cmov/libpthread.so.0
#2 0x08836f60 in my_write_core (sig=11) at stacktrace.c:426
#3 0x082bf70e in handle_segfault (sig=11) at mysqld.cc:2824
#4 <signal handler called>
#5 0x0842fcf3 in end_read_record (info=0xa696174) at records.cc:294
#6 0x08363291 in st_join_table::cleanup (this=0xa69611c) at sql_select.cc:9643
#7 0x083633a5 in JOIN::cleanup (this=0xa624f88, full=true) at sql_select.cc:9915
#8 0x083635fa in JOIN::join_free (this=0xa624f88) at sql_select.cc:9835
#9 0x08363cdb in do_select (join=0xa624f88, fields=0xa5a825c, table=0x0, procedure=0x0)
    at sql_select.cc:14809
#10 0x0837c6d7 in JOIN::exec (this=0xa624f88) at sql_select.cc:2679
#11 0x0837665c in mysql_select (thd=0xa5a6788, rref_pointer_array=0xa5a8304, tables=0xa617518,
    wild_num=1, fields=@0xa5a825c, conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0,
    proc_param=0x0, select_options=2147764736, result=0xa617f80, unit=0xa5a7ee8, select_lex=0xa5a81c8)
    at sql_select.cc:2900
#12 0x0837ca00 in handle_select (thd=0xa5a6788, lex=0xa5a7e8c, result=0xa617f80,
    setup_tables_done_option=0) at sql_select.cc:283
#13 0x082d1be0 in execute_sqlcom_select (thd=0xa5a6788, all_tables=0xa617518) at sql_parse.cc:5112
#14 0x082d42dd in mysql_execute_command (thd=0xa5a6788) at sql_parse.cc:2250
#15 0x082de07a in mysql_parse (thd=0xa5a6788,
    rawbuf=0xa6163d0 "SELECT * FROM (SELECT t1.* FROM t1, t2 ) AS alias1 JOIN t3 ON ( t3.a = alias1.b )", length=81, found_semicolon=0xaf101f6c) at sql_parse.cc:6112
#16 0x082decd5 in dispatch_command (command=COM_QUERY, thd=0xa5a6788, packet=0xa600451 "",
    packet_length=81) at sql_parse.cc:1221
#17 0x082e040d in do_command (thd=0xa5a6788) at sql_parse.cc:916
#18 0x082c9465 in handle_one_connection (arg=0xa5a6788) at sql_connect.cc:1191
#19 0xb7efc4ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#20 0xb7d4949e in clone () from /lib/tls/i686/cmov/libc.so.6

[Sergey Petrunia (sergefp)]

The problem is caused by this scenario:

- temporary table is created
- a READ_RECORD structure R is intialized, like this:

  R->table= $table;
  R->file = $table->file ;

- temporary table is filled to the point where it is converted from Heap to Aria. After the conversion,
  TABLE structure stays the same, while {table->file} pointer is changed (it used to point to a ha_heap
  object, now it points to a ha_maria object which is located at a different address)

However, R->file still has pointer to the (now deleted) ha_heap object. Attempt to access via that pointer causes the crash.

[Philip Stoev (pstoev-askmonty)]

bug https://bugs.launchpad.net/maria/+bug/848874 (found in September) has been marked a duplicate of this one.

[Sergey Petrunia (sergefp)]

See also this revision:

sp1r-mhansson/martin@riffraff.(none)-20080319133228-30204

it shows that the problem could be also repeated for INFORMATION_SCHEMA and was fixed there by patching the hole: updating read_record->file= read_record->table->file;