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

Connect Engine: CREATE TABLE memory leak

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Fixed
    • 10.0(EOL), 10.1(EOL)
    • 10.1.18, 10.0.28
    • None
    • 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 GNU/Linux

    Description

      Scenario:

      Bash console (it's mandatory to execute from the bash):
      1) mysql -h 127.0.0.1 --port=3306 -u user -ppassword db -e 'DROP TABLE IF EXISTS c1;'

      2) mysql -h 127.0.0.1 --port=3306 -u user -ppassword db -e 'CREATE TABLE c1 ENGINE=CONNECT TABLE_TYPE=MYSQL DBNAME='\''information_schema'\'' OPTION_LIST='\''host=127.0.0.1,port=33235,user=user,password=password'\'' `tabname`='\''tables'\'''

      This scenario leads to spending an additional 500 MB of virtual memory (don't know exactly about the physical memory) for each repetition. This memory is not released until you restart the mysql process. Remote database name and a table - can be any.

      Attachments

        Issue Links

          Activity

            Hi, I've looked into the problem a bit and I think I've found the leak in the connect_assisted_discovery function, ha_connect.cc : 5176

            PCONNECT    xp= NULL;
            PGLOBAL     g= GetPlug(thd, xp);
            

            Here PCONNECT is a pointer to an user_connect object and GetPlug is a wrapper what calls the GetUser function and assigns the result to its second argument. GetUser function in turn allocates a new user_connect object (or increments a refcounter of an existing one). Since in the end the only owner of the newly created user_connect object is the xp variable, the object have to be explicitly freed (in a manner of the ha_connect::~ha_connect function) via the variable before the end of the function, which is never done.
            Since deallocation of an user_connect object isn't trivial (mostly because of refcounters and integrated linked list) and the connect_assisted_discovery function has several return points, I think the best way to solve the problem is to add some kind of RAII-style guard class what implements proper deallocation of user_connect objects in destructor.

            Unfortunately I can't produce a proper patch right now, but I hope this will help to fix the bug.

            ekarav Egor Karavaev (Inactive) added a comment - Hi, I've looked into the problem a bit and I think I've found the leak in the connect_assisted_discovery function, ha_connect.cc : 5176 PCONNECT xp= NULL; PGLOBAL g= GetPlug(thd, xp); Here PCONNECT is a pointer to an user_connect object and GetPlug is a wrapper what calls the GetUser function and assigns the result to its second argument. GetUser function in turn allocates a new user_connect object (or increments a refcounter of an existing one). Since in the end the only owner of the newly created user_connect object is the xp variable, the object have to be explicitly freed (in a manner of the ha_connect::~ha_connect function) via the variable before the end of the function, which is never done. Since deallocation of an user_connect object isn't trivial (mostly because of refcounters and integrated linked list) and the connect_assisted_discovery function has several return points, I think the best way to solve the problem is to add some kind of RAII-style guard class what implements proper deallocation of user_connect objects in destructor. Unfortunately I can't produce a proper patch right now, but I hope this will help to fix the bug.

            Thanks for pointing out this and show where the problem was.

            bertrandop Olivier Bertrand added a comment - Thanks for pointing out this and show where the problem was.
            Sergey.Antonyuk Sergey Antonyuk added a comment - - edited

            I've checked the fix for version 10.1.24.
            The described scenario is fixed OK.
            But I've found exactly the same memory leak for the following extended scenario:

            1) mysql -h 127.0.0.1 --port=3306 -u user -ppassword db -e 'DROP TABLE IF EXISTS c1;'
            2) mysql -h 127.0.0.1 --port=3306 -u user -ppassword db -e 'CREATE TABLE c1 ENGINE=CONNECT TABLE_TYPE=MYSQL DBNAME='\''information_schema'\'' OPTION_LIST='\''host=127.0.0.1,port=33235,user=user,password=password'\'' `tabname`='\''tables'\'''
            3) mysql -h 127.0.0.1 --port=3306 -u user -ppassword db -e 'CREATE TABLE t1 AS SELECT * FROM c1'

            As you can see this is the same scenario continued by the third step.

            Sergey.Antonyuk Sergey Antonyuk added a comment - - edited I've checked the fix for version 10.1.24. The described scenario is fixed OK. But I've found exactly the same memory leak for the following extended scenario: 1) mysql -h 127.0.0.1 --port=3306 -u user -ppassword db -e 'DROP TABLE IF EXISTS c1;' 2) mysql -h 127.0.0.1 --port=3306 -u user -ppassword db -e 'CREATE TABLE c1 ENGINE=CONNECT TABLE_TYPE=MYSQL DBNAME='\''information_schema'\'' OPTION_LIST='\''host=127.0.0.1,port=33235,user=user,password=password'\'' `tabname`='\''tables'\''' 3) mysql -h 127.0.0.1 --port=3306 -u user -ppassword db -e 'CREATE TABLE t1 AS SELECT * FROM c1' As you can see this is the same scenario continued by the third step.

            Sergey.Antonyuk, thank you, would you mind creating a new bug report? A comment in a closed one is likely to be missed, and we normally don't re-open closed ones after the fix version was released, because it confuses the release history.

            elenst Elena Stepanova added a comment - Sergey.Antonyuk , thank you, would you mind creating a new bug report? A comment in a closed one is likely to be missed, and we normally don't re-open closed ones after the fix version was released, because it confuses the release history.

            Ok, it's clear now. I've created new bug report MDEV-13195.

            Sergey.Antonyuk Sergey Antonyuk added a comment - Ok, it's clear now. I've created new bug report MDEV-13195 .

            People

              bertrandop Olivier Bertrand
              Sergey.Antonyuk Sergey Antonyuk
              Votes:
              1 Vote for this issue
              Watchers:
              4 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.