Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-6212

TokuDB: memory leak in external_lock

Details

    Description

      A split from MDEV-6083. Please note that 5.5 is also affected, just comment out assertion in intern_sys_var_ptr().

      # It's not necessary to install TokuDB at runtime, 
      # instead the server can be run with --plugin-load=ha_tokudb
       
      INSTALL SONAME 'ha_tokudb';
      DROP TABLE IF EXISTS t1;
      CREATE TABLE t1 (a INT) ENGINE=TokuDB;
      INSERT INTO t1 VALUES (1),(2);
      UNINSTALL SONAME 'ha_tokudb';
       
      # Let server to shutdown (with MTR, it happens on its own)

      ==2806== 212 bytes in 1 blocks are still reachable in loss record 9 of 10
      ==2806==    at 0x4C28CCE: malloc (vg_replace_malloc.c:292)
      ==2806==    by 0xE3853F: sf_malloc (safemalloc.c:115)
      ==2806==    by 0xE276A6: my_malloc (my_malloc.c:100)
      ==2806==    by 0xD63B40C: ???
      ==2806==    by 0xD63EEA2: ???
      ==2806==    by 0xD64F7DE: ???
      ==2806==    by 0x869CC7: handler::ha_external_lock(THD*, int) (handler.cc:5843)
      ==2806==    by 0x93F723: lock_external(THD*, TABLE**, unsigned int) (lock.cc:357)
      ==2806==    by 0x93F4A3: mysql_lock_tables(THD*, st_mysql_lock*, unsigned int) (lock.cc:309)
      ==2806==    by 0x93F3B4: mysql_lock_tables(THD*, TABLE**, unsigned int, unsigned int) (lock.cc:276)
      ==2806==    by 0x61937F: lock_tables(THD*, TABLE_LIST*, unsigned int, unsigned int) (sql_base.cc:5310)
      ==2806==    by 0x618B3A: open_and_lock_tables(THD*, TABLE_LIST*, bool, unsigned int, Prelocking_strategy*) (sql_base.cc:5081)
      ==2806==    by 0x60D1E2: open_and_lock_tables(THD*, TABLE_LIST*, bool, unsigned int) (sql_base.h:485)
      ==2806==    by 0x655BE1: mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool) (sql_insert.cc:722)
      ==2806==    by 0x676262: mysql_execute_command(THD*) (sql_parse.cc:3471)
      ==2806==    by 0x67E48E: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:6452)

      Attachments

        Issue Links

          Activity

            prohaska7 Rich Prohaska added a comment -

            client runs the insert statement.

            tokudb::external lock sets thd->ha_data[tokudb_hton->slot] = malloced tokudb_trx_data.

            client uninstalls the tokudb plugin. the tokudb_hton->close_connection function does not get called, so the tokudb trx data does not get freed.

            valgrind proclaims a leak.

            IMO, the uninstall of the plugin should call the close_connection function for all THD's that have used the plugin. this is not happening.

            prohaska7 Rich Prohaska added a comment - client runs the insert statement. tokudb::external lock sets thd->ha_data [tokudb_hton->slot] = malloced tokudb_trx_data. client uninstalls the tokudb plugin. the tokudb_hton->close_connection function does not get called, so the tokudb trx data does not get freed. valgrind proclaims a leak. IMO, the uninstall of the plugin should call the close_connection function for all THD's that have used the plugin. this is not happening.

            Hi Rich,

            there is an API which should be used to set/get ha_data, which TokuDB doesn't seem to follow. For details please see the following revision:

            revno: 2661.599.1
            revision-id: svoj@sun.com-20100414095359-0sca2h1203eeybar
            parent: sergey.glukhov@sun.com-20100329134249-03wyhzp5k92dzhcb
            committer: Sergey Vojtovich <svoj@sun.com>
            branch nick: mysql-5.1-bugteam-bug39053
            timestamp: Wed 2010-04-14 13:53:59 +0400
            message:
              BUG#39053 - UNISTALL PLUGIN does not allow the storage engine
                          to cleanup open connections
             
              It was possible to UNINSTALL storage engine plugin when binding
              between THD object and storage engine is still active (e.g. in
              the middle of transaction).
             
              To avoid unclean deactivation (uninstall) of storage engine plugin
              in the middle of transaction, additional storage engine plugin
              lock is acquired by thd_set_ha_data().
             
              If ha_data is not null and storage engine plugin was not locked
              by thd_set_ha_data() in this connection before, storage engine
              plugin gets locked.
             
              If ha_data is null and storage engine plugin was locked by
              thd_set_ha_data() in this connection before, storage engine
              plugin lock gets released.
             
              If handlerton::close_connection() didn't reset ha_data, server does
              it immediately after calling handlerton::close_connection().
             
              Note that this is just a framework fix, storage engines must switch
              to thd_set_ha_data() from thd_ha_data() if they want to see fit.

            svoj Sergey Vojtovich added a comment - Hi Rich, there is an API which should be used to set/get ha_data, which TokuDB doesn't seem to follow. For details please see the following revision: revno: 2661.599.1 revision-id: svoj@sun.com-20100414095359-0sca2h1203eeybar parent: sergey.glukhov@sun.com-20100329134249-03wyhzp5k92dzhcb committer: Sergey Vojtovich <svoj@sun.com> branch nick: mysql-5.1-bugteam-bug39053 timestamp: Wed 2010-04-14 13:53:59 +0400 message: BUG#39053 - UNISTALL PLUGIN does not allow the storage engine to cleanup open connections   It was possible to UNINSTALL storage engine plugin when binding between THD object and storage engine is still active (e.g. in the middle of transaction).   To avoid unclean deactivation (uninstall) of storage engine plugin in the middle of transaction, additional storage engine plugin lock is acquired by thd_set_ha_data().   If ha_data is not null and storage engine plugin was not locked by thd_set_ha_data() in this connection before, storage engine plugin gets locked.   If ha_data is null and storage engine plugin was locked by thd_set_ha_data() in this connection before, storage engine plugin lock gets released.   If handlerton::close_connection() didn't reset ha_data, server does it immediately after calling handlerton::close_connection().   Note that this is just a framework fix, storage engines must switch to thd_set_ha_data() from thd_ha_data() if they want to see fit.
            prohaska7 Rich Prohaska added a comment -

            after using thd_set/ha_data and thd_ha_data, the memory leak still exists. in addition, this is now in the error log:

            140506 14:48:10 [ERROR] Plugin 'TokuDB' has ref_count=1 after shutdown.

            so, there is another problem. what event other than close_connection would get rid of the plugin reference?

            prohaska7 Rich Prohaska added a comment - after using thd_set/ha_data and thd_ha_data, the memory leak still exists. in addition, this is now in the error log: 140506 14:48:10 [ERROR] Plugin 'TokuDB' has ref_count=1 after shutdown. so, there is another problem. what event other than close_connection would get rid of the plugin reference?

            Could you share your patch? I can't remember at glance extra requirements, but this error in the log looks like a sign that we're on a right way.

            svoj Sergey Vojtovich added a comment - Could you share your patch? I can't remember at glance extra requirements, but this error in the log looks like a sign that we're on a right way.

            Rich,

            fwics TokuDB doesn't reset ha_data thus this error and memory leak. It should call thd_set_ha_data(thd, hton, NULL) whenever ha_data is not needed anymore. I suppose in case of TokuDB it is transaction commit/rollback/cancel/abort/whatever.

            svoj Sergey Vojtovich added a comment - Rich, fwics TokuDB doesn't reset ha_data thus this error and memory leak. It should call thd_set_ha_data(thd, hton, NULL) whenever ha_data is not needed anymore. I suppose in case of TokuDB it is transaction commit/rollback/cancel/abort/whatever.

            People

              Unassigned Unassigned
              svoj Sergey Vojtovich
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.