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
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
