MySQL Bugs: #56947: InnoDB leaks memory when failing to create a table

Bug #56947	InnoDB leaks memory when failing to create a table
Submitted:	22 Sep 2010 18:12	Modified:	10 Feb 2011 23:54
Reporter:	Alexey Kopytov	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: InnoDB Plugin storage engine	Severity:	S3 (Non-critical)
Version:	mysql-5.1-security	OS:	Linux (x86_64)
Assigned to:	Marko Mäkelä	CPU Architecture:	Any
Tags:	Leak, memory leak, valgrind

Description:
Splitting up bug #56709. The following leak reported by valgrind for the innodb-index test looks like an InnoDB problem:

==30019== 
==30019== HEAP SUMMARY:
==30019==     in use at exit: 2,366 bytes in 6 blocks
==30019==   total heap usage: 114,828 allocs, 114,822 frees, 510,849,743 bytes allocated
==30019== 
==30019== 14 bytes in 1 blocks are indirectly lost in loss record 1 of 6
==30019==    at 0x4C284A8: malloc (vg_replace_malloc.c:236)
==30019==    by 0x6DD7F19: ???
==30019==    by 0x6DD82C2: ???
==30019==    by 0x6D1CA89: ???
==30019==    by 0x6D9BE55: ???
==30019==    by 0x6D46E4B: ???
==30019==    by 0x815148: mysql_alter_table(THD*, char*, char*, st_ha_create_information*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool) (sql_table.cc:7328)
==30019==    by 0x69184A: mysql_execute_command(THD*) (sql_parse.cc:2968)
==30019==    by 0x69B17F: mysql_parse(THD*, char*, unsigned int, char const**) (sql_parse.cc:6051)
==30019==    by 0x68D434: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1260)
==30019==    by 0x68C401: do_command(THD*) (sql_parse.cc:888)
==30019==    by 0x68A158: handle_one_connection (sql_connect.cc:1136)
==30019==    by 0x4E349C9: start_thread (pthread_create.c:300)
==30019==    by 0x40BD70F: ???
==30019== 
==30019== 568 bytes in 1 blocks are indirectly lost in loss record 4 of 6
==30019==    at 0x4C284A8: malloc (vg_replace_malloc.c:236)
==30019==    by 0x6D62E42: ???
==30019==    by 0x6D61AB5: ???
==30019==    by 0x6D61D39: ???
==30019==    by 0x6D60705: ???
==30019==    by 0x6D60690: ???
==30019==    by 0x6D1CA44: ???
==30019==    by 0x6D9BE55: ???
==30019==    by 0x6D46E4B: ???
==30019==    by 0x815148: mysql_alter_table(THD*, char*, char*, st_ha_create_information*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool) (sql_table.cc:7328)
==30019==    by 0x69184A: mysql_execute_command(THD*) (sql_parse.cc:2968)
==30019==    by 0x69B17F: mysql_parse(THD*, char*, unsigned int, char const**) (sql_parse.cc:6051)
==30019==    by 0x68D434: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1260)
==30019==    by 0x68C401: do_command(THD*) (sql_parse.cc:888)
==30019==    by 0x68A158: handle_one_connection (sql_connect.cc:1136)
==30019==    by 0x4E349C9: start_thread (pthread_create.c:300)
==30019== 
==30019== 1,256 bytes in 1 blocks are indirectly lost in loss record 5 of 6
==30019==    at 0x4C284A8: malloc (vg_replace_malloc.c:236)
==30019==    by 0x6D62E42: ???
==30019==    by 0x6D61AB5: ???
==30019==    by 0x6D61D39: ???
==30019==    by 0x6D60705: ???
==30019==    by 0x6D1CB34: ???
==30019==    by 0x6D9BE55: ???
==30019==    by 0x6D46E4B: ???
==30019==    by 0x815148: mysql_alter_table(THD*, char*, char*, st_ha_create_information*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool) (sql_table.cc:7328)
==30019==    by 0x69184A: mysql_execute_command(THD*) (sql_parse.cc:2968)
==30019==    by 0x69B17F: mysql_parse(THD*, char*, unsigned int, char const**) (sql_parse.cc:6051)
==30019==    by 0x68D434: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1260)
==30019==    by 0x68C401: do_command(THD*) (sql_parse.cc:888)
==30019==    by 0x68A158: handle_one_connection (sql_connect.cc:1136)
==30019==    by 0x4E349C9: start_thread (pthread_create.c:300)
==30019==    by 0x40BD70F: ???
==30019== 
==30019== 2,062 (224 direct, 1,838 indirect) bytes in 1 blocks are definitely lost in loss record 6 of 6
==30019==    at 0x4C284A8: malloc (vg_replace_malloc.c:236)
==30019==    by 0x6D62E42: ???
==30019==    by 0x6D61AB5: ???
==30019==    by 0x6D60DBF: ???
==30019==    by 0x6D1CA2F: ???
==30019==    by 0x6D9BE55: ???
==30019==    by 0x6D46E4B: ???
==30019==    by 0x815148: mysql_alter_table(THD*, char*, char*, st_ha_create_information*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool) (sql_table.cc:7328)
==30019==    by 0x69184A: mysql_execute_command(THD*) (sql_parse.cc:2968)
==30019==    by 0x69B17F: mysql_parse(THD*, char*, unsigned int, char const**) (sql_parse.cc:6051)
==30019==    by 0x68D434: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1260)
==30019==    by 0x68C401: do_command(THD*) (sql_parse.cc:888)
==30019==    by 0x68A158: handle_one_connection (sql_connect.cc:1136)
==30019==    by 0x4E349C9: start_thread (pthread_create.c:300)
==30019==    by 0x40BD70F: ???
==30019== 
==30019== LEAK SUMMARY:
==30019==    definitely lost: 224 bytes in 1 blocks
==30019==    indirectly lost: 1,838 bytes in 3 blocks
==30019==      possibly lost: 0 bytes in 0 blocks
==30019==    still reachable: 0 bytes in 0 blocks
==30019==         suppressed: 304 bytes in 2 blocks
==30019== 
==30019== For counts of detected and suppressed errors, rerun with: -v
==30019== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 8)

How to repeat:
mysql-5.1-security, Linux/x86_64, BUILD/compile-pentium-valgrind-max-no-ndb

./mtr --mem --valgrind innodb-index

Thank you for the report.

Verified as described.

Stack traces for statically linked InnoDB Plugin:

==25495== 14 bytes in 1 blocks are possibly lost in loss record 1 of 3
==25495==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==25495==    by 0x8486622: ut_malloc_low (ut0mem.c:106)
==25495==    by 0x8486938: ut_malloc (ut0mem.c:244)
==25495==    by 0x84B8378: dict_mem_table_create (dict0mem.c:71)
==25495==    by 0x84593ED: row_merge_create_temporary_table (row0merge.c:2249)
==25495==    by 0x841BAD9: ha_innobase::add_index(st_table*, st_key*, unsigned int) (handler0alter.cc:741)

==25495== 168 bytes in 1 blocks are possibly lost in loss record 2 of 3
==25495==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==25495==    by 0x84331FF: mem_area_alloc (mem0pool.c:380)
==25495==    by 0x843244F: mem_heap_create_block (mem0mem.c:333)
==25495==    by 0x8431A51: mem_heap_create_func (mem0mem.ic:443)
==25495==    by 0x84B8324: dict_mem_table_create (dict0mem.c:64)
==25495==    by 0x84593ED: row_merge_create_temporary_table (row0merge.c:2249)
==25495==    by 0x841BAD9: ha_innobase::add_index(st_table*, st_key*, unsigned int) (handler0alter.cc:741)

==25495== 400 bytes in 1 blocks are possibly lost in loss record 3 of 3
==25495==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==25495==    by 0x84331FF: mem_area_alloc (mem0pool.c:380)
==25495==    by 0x843244F: mem_heap_create_block (mem0mem.c:333)
==25495==    by 0x8432672: mem_heap_add_block (mem0mem.c:446)
==25495==    by 0x843152D: mem_heap_alloc (mem0mem.ic:186)
==25495==    by 0x84314CB: mem_heap_zalloc (mem0mem.ic:154)
==25495==    by 0x84B833A: dict_mem_table_create (dict0mem.c:66)
==25495==    by 0x84593ED: row_merge_create_temporary_table (row0merge.c:2249)
==25495==    by 0x841BAD9: ha_innobase::add_index(st_table*, st_key*, unsigned int) (handler0alter.cc:741)

The reason why Valgrind does not report this memory leak in InnoDB versions before the Plugin 1.0 is that they do not implement innodb_use_sys_malloc=1. That is, an attempt to re-CREATE an InnoDB table whose .frm file does not exist will leak memory. Valgrind will not complain, because the leaked blocks will be collected by ut_free_all_mem() at server shutdown.

Added to the change log:

A failed CREATE TABLE statement for an InnoDB table could allocate
memory that was never freed

Bug #56381 may be a duplicate of this one.

Pushed into mysql-5.1 5.1.54 (revid:build@mysql.com-20101118153531-693taxtxyxpt037i) (version source revid:build@mysql.com-20101118153531-693taxtxyxpt037i) (merge vers: 5.1.54) (pib:21)

Pushed into mysql-trunk 5.6.1 (revid:alexander.nozdrin@oracle.com-20101205122447-6x94l4fmslpbttxj) (version source revid:alexander.nozdrin@oracle.com-20101205122447-6x94l4fmslpbttxj) (merge vers: 5.6.1) (pib:23)

Pushed into mysql-trunk 5.6.1 (revid:alexander.nozdrin@oracle.com-20101216181820-7afubgk2fmuv9qsb) (version source revid:alexander.nozdrin@oracle.com-20101216173826-ze3y5h450sksotrh) (merge vers: 5.6.1) (pib:23)

Pushed into mysql-5.5 5.5.9 (revid:jonathan.perkin@oracle.com-20101216101358-fyzr1epq95a3yett) (version source revid:jonathan.perkin@oracle.com-20101216101358-fyzr1epq95a3yett) (merge vers: 5.5.9) (pib:24)

launchpad is down and I can't pull changes. This doesn't have a link to the commit. Has the practice of including that stopped?

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/130118

3300 Vasil Dimov	2011-02-01
      Replay a lost change (fix for Bug#56947 InnoDB leaks memory... in 5.5)
      
      This change was originally done in
      marko.makela@oracle.com-20101011085943-50pskvsbbsujbukg
      but was later lost during the merge process.

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/130149

3301 Vasil Dimov	2011-02-01
      Replay a lost change (fix for Bug#56947 InnoDB leaks memory... in 5.5)
      
      This change was originally done in
      marko.makela@oracle.com-20101011085943-50pskvsbbsujbukg
      but was later lost during the merge process.

Pushed into mysql-trunk 5.6.2 (revid:vasil.dimov@oracle.com-20110208173442-ocy58fdcuew3xvex) (version source revid:vasil.dimov@oracle.com-20110208173331-fu0j2s14jbg915zu) (merge vers: 5.6.2) (pib:24)

Pushed into mysql-5.5 5.5.10 (revid:vasil.dimov@oracle.com-20110208173046-qsmzbrw1gppahx5o) (version source revid:vasil.dimov@oracle.com-20110208172800-tls70r2ot1i0dub7) (merge vers: 5.5.10) (pib:24)