maria-developers team mailing list archive

[Sergey Petrunya <psergey@xxxxxxxxxxxx>]

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