3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 GNU/Linux

I'm not getting any memory growth with the described scenario, neither on the current tree nor on 10.1.12 build.

Does the server on port 33235 exist? Or more generally, is the table creation in the scenario successful?
If the server does exist, how many tables (entries in information_schema.tables) does it have?

Please also attach your cnf file(s).

Thanks.

Yes, the server exists and the table created. Port 33235 is the ssh tunnel to remote MariaDB 10.1.12 but it doesn't matter because the following loopback also leads to the problem:
mysql -h 127.0.0.1 --port=3306 -u root -ppassword syn_db -e 'CREATE TABLE c1 ENGINE=CONNECT TABLE_TYPE=MYSQL DBNAME='\''information_schema'\'' OPTION_LIST='\''host=127.0.0.1,port=3306,user=root,password=password'\'' `tabname`='\''ENGINES'\'''

The table ENGINES have 9 rows and the memory leaks the same way.

The problem doesn't reproduce if I execute the commands from the open mysql console. It's mandatory to use shell to reproduce the problem.

Memory leak is directly correlated with "connect_work_size" variable. It equals 1000M in my case.

Thanks, I can reproduce it now.
The important parameter in the config file is thread-cache-size. If it's set to any value (even to 1), the described problem happens – memory usage grows by connect_work_size value on every iteration in the scenario above.

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.

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.

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