[MDEV-29628] Memory leak after CREATE OR REPLACE with foreign key Created: 2022-09-24  Updated: 2023-05-18  Resolved: 2023-01-25

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Create Table
Affects Version/s: None
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Aleksey Midenkov Assignee: Aleksey Midenkov
Resolution: Fixed Votes: 0
Labels: regression

Issue Links:
Problem/Incident
is caused by MDEV-25292 Atomic CREATE OR REPLACE TABLE Stalled

 Description   

Tests main.create_or_replace, versioning.foreign display memory leaks:

==1964507== Thread 1:
 
==1964507== 616 bytes in 1 blocks are indirectly lost in loss record 1 of 2
 
==1964507==    at 0x4844899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
 
==1964507==    by 0x12C551E: ut_allocator<unsigned char, true>::allocate(unsigned long, unsigned char const*, unsigned int, bool, bool) (ut0new.h:375)
 
==1964507==    by 0x13ADCF9: mem_heap_create_block_func(mem_block_info_t*, unsigned long, char const*, unsigned int, unsigned long) (mem0mem.cc:277)
 
==1964507==    by 0x13AE104: mem_heap_add_block(mem_block_info_t*, unsigned long) (mem0mem.cc:378)
 
==1964507==    by 0x16207DD: mem_heap_alloc(mem_block_info_t*, unsigned long) (mem0mem.inl:193)
 
==1964507==    by 0x16206A7: mem_heap_zalloc(mem_block_info_t*, unsigned long) (mem0mem.inl:162)
 
==1964507==    by 0x16247F7: dict_mem_foreign_create() (dict0mem.cc:802)
 
==1964507==    by 0x12A444B: create_table_info_t::create_foreign_keys() (ha_innodb.cc:12329)
 
==1964507==    by 0x12A5E35: create_table_info_t::create_table(bool) (ha_innodb.cc:12826)
 
==1964507==    by 0x12C4235: ha_innobase::create(char const*, TABLE*, HA_CREATE_INFO*, bool, trx_t*) (ha_innodb.cc:13282)
 
==1964507==    by 0x12A6D36: ha_innobase::create(char const*, TABLE*, HA_CREATE_INFO*) (ha_innodb.cc:13320)
 
==1964507==    by 0xEB6072: handler::ha_create(char const*, TABLE*, HA_CREATE_INFO*) (handler.cc:5463)
 
==1964507==    by 0xEB7A4D: ha_create_table(THD*, char const*, char const*, char const*, HA_CREATE_INFO*, st_mysql_const_unsigned_lex_string*, bool) (handler.cc:5932)
 
==1964507==    by 0xBCECCB: create_table_impl(THD*, st_mysql_const_lex_string const&, st_mysql_const_lex_string const&, st_mysql_const_lex_string const&, st_mysql_const_lex_string const&, st_mysql_const_lex_string const&, DDL_options_st, HA_CREATE_INFO*, Alter_info*, int, bool*, st_key**, unsigned int*, st_mysql_const_unsigned_lex_string*) (sql_table.cc:4949)
 
==1964507==    by 0xBCF282: mysql_create_table_no_lock(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, Table_specification_st*, Alter_info*, bool*, int, TABLE_LIST*, st_mysql_const_unsigned_lex_string*) (sql_table.cc:5076)
 
==1964507==    by 0xBCF9BD: mysql_create_table(THD*, TABLE_LIST*, Table_specification_st*, Alter_info*) (sql_table.cc:5203)
 
==1964507== 
==1964507== 872 (256 direct, 616 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 2
 
==1964507==    at 0x4844899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
 
==1964507==    by 0x12C551E: ut_allocator<unsigned char, true>::allocate(unsigned long, unsigned char const*, unsigned int, bool, bool) (ut0new.h:375)
 
==1964507==    by 0x13ADCF9: mem_heap_create_block_func(mem_block_info_t*, unsigned long, char const*, unsigned int, unsigned long) (mem0mem.cc:277)
 
==1964507==    by 0x1620881: mem_heap_create_func(unsigned long, char const*, unsigned int, unsigned long) (mem0mem.inl:377)
 
==1964507==    by 0x16247E2: dict_mem_foreign_create() (dict0mem.cc:799)
 
==1964507==    by 0x12A444B: create_table_info_t::create_foreign_keys() (ha_innodb.cc:12329)
 
==1964507==    by 0x12A5E35: create_table_info_t::create_table(bool) (ha_innodb.cc:12826)
 
==1964507==    by 0x12C4235: ha_innobase::create(char const*, TABLE*, HA_CREATE_INFO*, bool, trx_t*) (ha_innodb.cc:13282)
 
==1964507==    by 0x12A6D36: ha_innobase::create(char const*, TABLE*, HA_CREATE_INFO*) (ha_innodb.cc:13320)
 
==1964507==    by 0xEB6072: handler::ha_create(char const*, TABLE*, HA_CREATE_INFO*) (handler.cc:5463)
 
==1964507==    by 0xEB7A4D: ha_create_table(THD*, char const*, char const*, char const*, HA_CREATE_INFO*, st_mysql_const_unsigned_lex_string*, bool) (handler.cc:5932)
 
==1964507==    by 0xBCECCB: create_table_impl(THD*, st_mysql_const_lex_string const&, st_mysql_const_lex_string const&, st_mysql_const_lex_string const&, st_mysql_const_lex_string const&, st_mysql_const_lex_string const&, DDL_options_st, HA_CREATE_INFO*, Alter_info*, int, bool*, st_key**, unsigned int*, st_mysql_const_unsigned_lex_string*) (sql_table.cc:4949)
 
==1964507==    by 0xBCF282: mysql_create_table_no_lock(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, Table_specification_st*, Alter_info*, bool*, int, TABLE_LIST*, st_mysql_const_unsigned_lex_string*) (sql_table.cc:5076)
 
==1964507==    by 0xBCF9BD: mysql_create_table(THD*, TABLE_LIST*, Table_specification_st*, Alter_info*) (sql_table.cc:5203)
 
==1964507==    by 0xBE7860: Sql_cmd_create_table_like::execute(THD*) (sql_table.cc:12797)
 
==1964507==    by 0xAAE4B1: mysql_execute_command(THD*, bool) (sql_parse.cc:5997)
 
==1964507==



 Comments   
Comment by Aleksey Midenkov [ 2022-09-24 ]

Please review bb-10.11-midenok

Comment by Marko Mäkelä [ 2022-09-26 ]

The code change looks OK to me, but the test main.create_or_replace seems to fail on every single platform. However, AddressSanitizer does not report anything.

The branch contains 2 other commits. A test for MDEV-29544 is messing with system table definitions, which may explain the test failure.

The branch is based on a stale version of the 10.11 branch.

Generated at Thu Feb 08 10:10:04 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.