Description:
when a federated table cannot be opened due to some error (such as network problems or
somebody killed the connection, etc) there is a memory leak.
Valgrind outputs shows the location:
1) create or replace view v1 as select * from federated_table;
16,752 bytes in 349 blocks are definitely lost in loss record 7 of 7
malloc (vg_replace_malloc.c:149)
my_strdup_with_length (my_malloc.c:34)
parse_url() (ha_federated.cc:571)
get_share() (ha_federated.cc:1273)
ha_federated::open() (ha_federated.cc:1400)
handler::ha_open() (handler.cc:1409)
openfrm() (table.cc:929)
open_unireg_entry() (sql_base.cc:2545)
open_table() (sql_base.cc:1919)
open_tables() (sql_base.cc:2758)
open_and_lock_tables() (sql_base.cc:3057)
mysql_create_view() (sql_view.cc:470)
2) select * from federated_table:
3,024 bytes in 63 blocks are definitely lost in loss record 7 of 7
malloc (vg_replace_malloc.c:149)
my_strdup_with_length (my_malloc.c:34)
parse_url() (ha_federated.cc:571)
get_share() (ha_federated.cc:1273)
ha_federated::open() (ha_federated.cc:1400)
handler::ha_open() (handler.cc:1409)
openfrm() (table.cc:929)
open_unireg_entry() (sql_base.cc:2545)
open_table() (sql_base.cc:1919)
open_tables() (sql_base.cc:2758)
open_and_lock_tables() (sql_base.cc:3057)
mysql_execute_command() (sql_parse.cc:3110)
How to repeat:
check the code. I will also upload a .c testcase to be run when mysqld is under
valgrind. The testcase will randomly kill connections to force failures in the code.
Suggested fix:
cleanup the memory in path of error execution.
