[Maria-developers] Help with memory leak in EXPLAIN
Hi Sergey, I encountered a memory leak while working on fixing the MySQL 5.1.41 merge. The memory leak is repeatable with the following test case: ------------------------------ cut here ------------------------------ # # Bug#45989 memory leak after explain encounters an error in the query # CREATE TABLE t1(a LONGTEXT); INSERT INTO t1 VALUES (repeat('a',@@global.max_allowed_packet)); INSERT INTO t1 VALUES (repeat('b',@@global.max_allowed_packet)); --error ER_BAD_FIELD_ERROR EXPLAIN SELECT DISTINCT 1 FROM t1, (SELECT DISTINCTROW a AS away FROM t1 GROUP BY a WITH ROLLUP) as d1 WHERE t1.a = d1.a; DROP TABLE t1; ------------------------------ cut here ------------------------------ perl mysql-test-run.pl --valgrind kn.test Errors/warnings were found in logfiles during server shutdown after running the following sequence(s) of tests: main.kn ==14709== 1,048,584 bytes in 1 blocks are possibly lost in loss record 7 of 7 ==14709== at 0x4C22FAB: malloc (vg_replace_malloc.c:207) ==14709== by 0xB1DDD0: my_malloc (my_malloc.c:37) ==14709== by 0x6691C1: String::real_alloc(unsigned) (sql_string.cc:43) ==14709== by 0x5D7BFF: String::alloc(unsigned) (sql_string.h:210) ==14709== by 0x669835: String::copy(String const&) (sql_string.cc:192) ==14709== by 0x7E8BB0: do_save_blob(Copy_field*) (field_conv.cc:296) ==14709== by 0x7E6922: do_copy_null(Copy_field*) (field_conv.cc:207) ==14709== by 0x6EB28B: copy_fields(TMP_TABLE_PARAM*) (sql_select.cc:15374) ==14709== by 0x6F7F1B: end_write_group(JOIN*, st_join_table*, bool) (sql_select.cc:12715) ==14709== by 0x6F4415: evaluate_join_record(JOIN*, st_join_table*, int) (sql_select.cc:11514) ==14709== by 0x6F464E: sub_select(JOIN*, st_join_table*, bool) (sql_select.cc:11399) ==14709== by 0x705B1E: do_select(JOIN*, List<Item>*, st_table*, Procedure*) (sql_select.cc:11155) ==14709== by 0x7161C2: JOIN::exec() (sql_select.cc:1809) ==14709== by 0x7127B6: mysql_select(THD*, Item***, TABLE_LIST*, unsigned, List<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:2425) ==14709== by 0x82EEEB: mysql_derived_filling(THD*, st_lex*, TABLE_LIST*) (sql_derived.cc:294) ==14709== by 0x82EC8B: mysql_handle_derived(st_lex*, bool (*)(THD*, st_lex*, TABLE_LIST*)) (sql_derived.cc:56) This bug is also in main lp:maria MariaDB trunk, and also in current MySQL (there is a MySQL bug, http://bugs.mysql.com/bug.php?id=45989). Could you take a look, and see if it is something you/we could fix, or if you have any other suggestions for how to deal with this? - Kristian.
Hi Kristian, On Wed, Nov 25, 2009 at 04:05:27PM +0100, Kristian Nielsen wrote:
I encountered a memory leak while working on fixing the MySQL 5.1.41 merge.
The memory leak is repeatable with the following test case:
------------------------------ cut here ------------------------------ # # Bug#45989 memory leak after explain encounters an error in the query # CREATE TABLE t1(a LONGTEXT); INSERT INTO t1 VALUES (repeat('a',@@global.max_allowed_packet)); INSERT INTO t1 VALUES (repeat('b',@@global.max_allowed_packet)); --error ER_BAD_FIELD_ERROR EXPLAIN SELECT DISTINCT 1 FROM t1, (SELECT DISTINCTROW a AS away FROM t1 GROUP BY a WITH ROLLUP) as d1 WHERE t1.a = d1.a; DROP TABLE t1; ------------------------------ cut here ------------------------------
perl mysql-test-run.pl --valgrind kn.test
Errors/warnings were found in logfiles during server shutdown after running the following sequence(s) of tests: main.kn
==14709== 1,048,584 bytes in 1 blocks are possibly lost in loss record 7 of 7 ==14709== at 0x4C22FAB: malloc (vg_replace_malloc.c:207) ==14709== by 0xB1DDD0: my_malloc (my_malloc.c:37) ==14709== by 0x6691C1: String::real_alloc(unsigned) (sql_string.cc:43) ==14709== by 0x5D7BFF: String::alloc(unsigned) (sql_string.h:210) ==14709== by 0x669835: String::copy(String const&) (sql_string.cc:192) ==14709== by 0x7E8BB0: do_save_blob(Copy_field*) (field_conv.cc:296) ==14709== by 0x7E6922: do_copy_null(Copy_field*) (field_conv.cc:207) ==14709== by 0x6EB28B: copy_fields(TMP_TABLE_PARAM*) (sql_select.cc:15374) ==14709== by 0x6F7F1B: end_write_group(JOIN*, st_join_table*, bool) (sql_select.cc:12715) ==14709== by 0x6F4415: evaluate_join_record(JOIN*, st_join_table*, int) (sql_select.cc:11514) ==14709== by 0x6F464E: sub_select(JOIN*, st_join_table*, bool) (sql_select.cc:11399) ==14709== by 0x705B1E: do_select(JOIN*, List<Item>*, st_table*, Procedure*) (sql_select.cc:11155) ==14709== by 0x7161C2: JOIN::exec() (sql_select.cc:1809) ==14709== by 0x7127B6: mysql_select(THD*, Item***, TABLE_LIST*, unsigned, List<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:2425) ==14709== by 0x82EEEB: mysql_derived_filling(THD*, st_lex*, TABLE_LIST*) (sql_derived.cc:294) ==14709== by 0x82EC8B: mysql_handle_derived(st_lex*, bool (*)(THD*, st_lex*, TABLE_LIST*)) (sql_derived.cc:56)
This bug is also in main lp:maria MariaDB trunk, and also in current MySQL (there is a MySQL bug, http://bugs.mysql.com/bug.php?id=45989).
Could you take a look, and see if it is something you/we could fix, or if you have any other suggestions for how to deal with this?
It seems the fix for the bug was lost in the merge: === modified file 'sql/sql_select.cc' --- sql/sql_select.cc 2009-11-16 20:54:33 +0000 +++ sql/sql_select.cc 2009-11-26 12:26:59 +0000 @@ -2311,7 +2311,7 @@ JOIN::destroy() tab->cleanup(); } tmp_join->tmp_join= 0; - tmp_table_param.copy_field= 0; + tmp_table_param.cleanup(); DBUG_RETURN(tmp_join->destroy()); } cond_equal= 0; After I apply it, the leak goes away. -- BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog
participants (2)
-
Kristian Nielsen -
Sergey Petrunya