Description:
when you have two differently defined federated tables both pointing to the same base table, and at least one is in the table_cache, selecting from the other can cause a crash:
mysqld-debug.exe!memcpy()[memcpy.asm:192]
mysqld-debug.exe!well_formed_copy_nchars()[sql_string.cc:942]
mysqld-debug.exe!Field_blob::store()[field.cc:7036]
mysqld-debug.exe!ha_federated::convert_row_to_internal_format()[ha_federated.cc:743]
mysqld-debug.exe!ha_federated::read_next()[ha_federated.cc:2454]
mysqld-debug.exe!ha_federated::rnd_next()[ha_federated.cc:2418]
mysqld-debug.exe!rr_sequential()[records.cc:332]
mysqld-debug.exe!join_init_read_record()[sql_select.cc:11345]
mysqld-debug.exe!sub_select()[sql_select.cc:10680]
mysqld-debug.exe!do_select()[sql_select.cc:10444]
mysqld-debug.exe!JOIN::exec()[sql_select.cc:2106]
mysqld-debug.exe!mysql_select()[sql_select.cc:2287]
mysqld-debug.exe!handle_select()[sql_select.cc:257]
mysqld-debug.exe!mysql_execute_command()[sql_parse.cc:2789]
mysqld-debug.exe!mysql_parse()[sql_parse.cc:6267]
mysqld-debug.exe!dispatch_command()[sql_parse.cc:1940]
mysqld-debug.exe!do_command()[sql_parse.cc:1628]
mysqld-debug.exe!handle_one_connection()[sql_parse.cc:1234]
mysqld-debug.exe!pthread_start()[my_winthread.c:85]
mysqld-debug.exe!_callthreadstart()[thread.c:295]
mysqld-debug.exe!_threadstart()[thread.c:277]
kernel32.dll!BaseThreadStart()
ariables.
invalid and cause the dump to abort...
0004888128=select * from f
A workaround is to set --table_cache=1 in my.cnf.
Doesn't appear to affect 5.1.30.
How to repeat:
flush tables;
drop table if exists `t1`,`aaaaa`,`f`;
create table `t1` (`a` int(10) not null,`b` int(10) not null,`c` text);
create table `aaaaa`(`a` int(10) not null) engine=federated connection='mysql://root@127.0.0.1:3306/test/t1';
create table `f` (`a` int(10) not null,`b` int(10) not null,`c` text)engine=federated connection='mysql://root@127.0.0.1:3306/test/t1';
insert into t1(a) values (0);
select * from `aaaaa`;
select * from f;
Run 5.0.74 under valgrind if the above doesn't crash.