MySQL Bugs: #56380: valgrind memory leak warning from partition tests

Bug #56380	valgrind memory leak warning from partition tests
Submitted:	30 Aug 2010 18:07	Modified:	26 Jan 2011 15:17
Reporter:	Mark Callaghan	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Partitions	Severity:	S2 (Serious)
Version:	5.1.50	OS:	Any
Assigned to:	Mattias Jonsson	CPU Architecture:	Any
Tags:	mtr, partitioning, valgrind

Description:
This is generated on mysqld shutdown, not at test end.

40 bytes in 1 blocks are definitely lost in loss record 1 of 2
   at 0x4A05809: malloc (vg_replace_malloc.c:149)
   by 0x7B20B1: my_malloc (my_malloc.c:35)
   by 0x59C68B: String::real_alloc(unsigned) (sql_string.cc:51)
   by 0x542194: Item_extract::fix_length_and_dec() (sql_string.h:205)
   by 0x510B43: Item_func::fix_fields(THD*, Item**) (item_func.cc:198)
   by 0x4E73AF: fix_fields_part_func(THD*, Item*, st_table*, bool, bool, bool) (sql_partition.cc:987)
   by 0x4E9969: fix_partition_func(THD*, st_table*, bool) (sql_partition.cc:1686)
   by 0x60300C: open_table_from_share(THD*, st_table_share*, char const*, unsigned, unsigned, unsigned, st_table*, bool) (table.cc:1853)
   by 0x6AD362: ha_create_table(THD*, char const*, char const*, char const*, st_ha_create_information*, bool) (handler.cc:3600)
   by 0x66AD07: rea_create_table(THD*, char const*, char const*, char const*, st_ha_create_information*, List<Create_field>&, unsigned, st_key*, handler*) (unireg.cc:421)
   by 0x6C660B: mysql_create_table_no_lock(THD*, char const*, char const*, st_ha_create_information*, Alter_info*, bool, unsigned) (sql_table.cc:3978)
   by 0x6CAEF1: mysql_alter_table(THD*, char*, char*, st_ha_create_information*, TABLE_LIST*, Alter_info*, unsigned, st_order*, bool) (sql_table.cc:7227)
   by 0x5B7134: mysql_execute_command(THD*) (sql_parse.cc:2949)
   by 0x5B815E: mysql_parse(THD*, char*, unsigned, char const**) (sql_parse.cc:6032)
   by 0x5B9398: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1260)
   by 0x5BA36B: do_command(THD*) (sql_parse.cc:888)

How to repeat:
I think I have narrowed it to this list:

./mysql-test-run.pl  --valgrind --force main.partition_disabled main.partition_open_files_limit main.partition main.partition_not_windows main.information_schema_part main.not_partition main.partition_archive main.partition_blackhole main.partition_bug18198 main.partition_charset main.partition_csv main.partition_datatype main.partition_debug_sync main.partition_error main.partition_federated main.partition_grant main.partition_hash main.partition_list main.partition_mgm main.partition_mgm_err main.partition_mgm_err2 main.partition_not_embedded main.partition_order main.partition_pruning main.partition_range main.partition_rename_longfilename main.partition_symlink main.partition_windows tablelock timezone

configure as:
./configure --enable-thread-safe-client --with-plugins=partition,csv,blackhole,myisam,heap,innodb_plugin --without-plugin-innobase --with-fast-mutexes --with-extra-charsets=all --with-debug C_EXTRA_FLAGS="-fno-omit-frame-pointer -fno-strict-aliasing -DHAVE_purify -DNO_ALARM -DSIGNAL_WITH_VIO_CLOSE -Wall"

host is centos 5.2

gcc --version
gcc (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42)

valgrind --version
valgrind-3.2.1

Is there an option to restart mysqld after each test? That would make it easier to find the problem.

Thank you for the report.

Verified as described:

40 bytes in 1 blocks are definitely lost in loss record 1 of 3
   at 0x4A05809: malloc (vg_replace_malloc.c:149)
   by 0x7C3544: my_malloc (my_malloc.c:35)
   by 0x5A0042: String::real_alloc(unsigned) (sql_string.cc:51)
   by 0x545FF5: Item_extract::fix_length_and_dec() (sql_string.h:205)
   by 0x5129FB: Item_func::fix_fields(THD*, Item**) (item_func.cc:198)
   by 0x4E1C17: T.1035 (sql_partition.cc:987)
   by 0x4E66D7: fix_partition_func(THD*, st_table*, bool) (sql_partition.cc:1686)
   by 0x5FF9D0: open_table_from_share(THD*, st_table_share*, char const*, unsigned, unsigned, unsigned, st_table*, bool) (table.cc:1853)
   by 0x6B4085: ha_create_table(THD*, char const*, char const*, char const*, st_ha_create_information*, bool) (handler.cc:3600)
   by 0x66B4EE: rea_create_table(THD*, char const*, char const*, char const*, st_ha_create_information*, List<Create_field>&, unsigned, st_key*, handler*) (unireg.cc:421)
   by 0x6D0EE8: mysql_create_table_no_lock(THD*, char const*, char const*, st_ha_create_information*, Alter_info*, bool, unsigned) (sql_table.cc:3978)
   by 0x6D29EF: mysql_alter_table(THD*, char*, char*, st_ha_create_information*, TABLE_LIST*, Alter_info*, unsigned, st_order*, bool) (sql_table.cc:7227)
   by 0x5B8925: mysql_execute_command(THD*) (sql_parse.cc:2949)
   by 0x5BC1DA: mysql_parse(THD*, char*, unsigned, char const**) (sql_parse.cc:6032)
   by 0x5BC787: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1260)
   by 0x5BDCA4: do_command(THD*) (sql_parse.cc:888)

Not repeatable with Valgrind 3.5.0

This is main.partition_error which caused error.

Seems related to bug#56996 and bug#46949. I have not yet managed to repeat it.

Managed to repeat it with the source for 5.1.50, but not with the current 5.1. Verified that the patch in bug#46949 solves the problem.

The valgrind error does not occur after the fix in bug#56709. Will commit a fix in the partitioning layer to prevent future memleaks on failing ALTER PARTITION statements.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/125638

3533 Mattias Jonsson	2010-12-01
      Bug#56380: valgrind memory leak warning from partition tests
      
      There could be memory leaks if ALTER ... PARTITION command fails.
      
      Problem was that the list of items to free was not set in
      the partition info structure when fix_partition_func call failed
      during ALTER ... PARTITION.
      
      Solved by always setting the list in the partition info struct.
     @ sql/table.cc
        item_free_list is not set if (!work_part_info_used) and
        fix_partition_func failed. Which may result in a mem leak.

Marked bug#46949 and bug#56996 as duplicates of this bug.

Not repeatable with latest 5.1 for me too.

Pushed into mysql-trunk 5.6.2 (revid:mattias.jonsson@oracle.com-20110110163747-ssccpoh0wesjl68q) (version source revid:mattias.jonsson@oracle.com-20110110163747-ssccpoh0wesjl68q) (merge vers: 5.6.2) (pib:24)

Pushed into mysql-5.5 5.5.9 (revid:mattias.jonsson@oracle.com-20110110160254-zodzbuutmr53468f) (version source revid:mattias.jonsson@oracle.com-20110110160254-zodzbuutmr53468f) (merge vers: 5.5.9) (pib:24)

Pushed into mysql-5.1 5.1.55 (revid:mattias.jonsson@oracle.com-20110110115627-2bj4218kve40go1r) (version source revid:mattias.jonsson@oracle.com-20110110115627-2bj4218kve40go1r) (merge vers: 5.1.55) (pib:24)

Documented bugfix in the 5.1.55, 5.5.9, and 5.6.2 changelogs, as follows:

        Failed ALTER TABLE ... PARTITION statements could cause memory 
        leaks.

Closed.