[MDEV-4066] semisync_master + temporary tables causes memory leaks Created: 2013-01-17  Updated: 2013-03-07  Resolved: 2013-03-07

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.0, 10.0.1, 5.5.29
Fix Version/s: 10.0.2, 5.5.30

Type: Bug Priority: Major
Reporter: Pavel Ivanov Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: upstream


 Description   

When connection closes THD::cleanup() is called, it calls close_temporary_tables(), which in turn calls MYSQL_BIN_LOG::write() to write DROP TABLE record into binlog. After record is written MYSQL_BIN_LOG::write() calls Binlog_storage_delegate::after_flush() if any observers are registered (I believe only semisync_master implements this observer currently). And here Trans_binlog_info is allocated which is supposed to be released in Trans_delegate::after_commit() or Trans_delegate::after_rollback(). But neither THD::cleanup() nor its callers commit/rollback the transaction and thus Trans_binlog_info is leaking.

 Comments   
Comment by Elena Stepanova [ 2013-01-18 ]

With the test case below, I'm getting a valgrind error. Reproducible on MySQL 5.5 and MariaDB 5.5, 10.0. Not reproducible on MySQL 5.6, so apparently it's fixed there; but it's worth checking whether the fix will apply to MariaDB, and decide if it needs to be fixed in 5.5 as well (I've added 5.5 to the fix versions for now).

  1. Test case (run with valgrind):

source include/have_semisync_plugin.inc;
source include/master-slave.inc;
source include/have_binlog_format_row.inc;

connection master;

eval INSTALL PLUGIN rpl_semi_sync_master SONAME '$SEMISYNC_MASTER_SO';

--connect (con1,localhost,root,,)
CREATE TEMPORARY TABLE tmp (i INT);
--disconnect con1

  1. no need to synchronize
  1. End of test case

Warning: 520 bytes lost, allocated at sql/rpl_handler.cc:300, sql/log.cc:5469, sql/sql_base.cc:1807, sql/sql_class.cc:1417, sql/mysqld.cc:2439, sql/mysqld.cc:2473, sql/mysqld.cc:2597, sql/sql_connect.cc:1264
Memory lost: 520 bytes in 1 chunks
==24797== 620 bytes in 1 blocks are still reachable in loss record 4 of 4
==24797== at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==24797== by 0xCC9406: sf_malloc (safemalloc.c:105)
==24797== by 0xCB3E3B: my_malloc (my_malloc.c:41)
==24797== by 0x71DEDC: Binlog_storage_delegate::after_flush(THD*, char const*, unsigned long long, bool) (rpl_handler.cc:300)
==24797== by 0x89F41B: MYSQL_BIN_LOG::write(Log_event*, char*) (log.cc:5469)
==24797== by 0x5AD4E6: close_temporary_tables(THD*) (sql_base.cc:1807)
==24797== by 0x5D3A25: THD::cleanup() (sql_class.cc:1416)
==24797== by 0x55DB2D: thd_cleanup(THD*) (mysqld.cc:2438)
==24797== by 0x55DBE9: unlink_thd(THD*) (mysqld.cc:2472)
==24797== by 0x55E014: one_thread_per_connection_end(THD*, bool) (mysqld.cc:2595)
==24797== by 0x7187BC: do_handle_one_connection(THD*) (sql_connect.cc:1264)
==24797== by 0x718101: handle_one_connection (sql_connect.cc:1168)
==24797== by 0xBA313E: pfs_spawn_thread (pfs.cc:1015)
==24797== by 0x5458EFB: start_thread (pthread_create.c:304)
==24797== by 0x611AF4C: clone (clone.S:112)

Comment by Sergei Golubchik [ 2013-03-07 ]

pushed in 5.5

Generated at Thu Feb 08 06:53:27 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.