Bug #35509 Federated leaks memory when connecting to localhost/default port

Description:
When creating federated table, which points to localhost and port is not specified or 0 (=default), connect string parser makes a copy of socket path, which is not freed. The problem was discovered with a test case for BUG#34788. Affects 5.0 only.

How to repeat:
Run mysqld under valgrind.
create table t1(a int) engine=federated connection='mysql://root@localhost/test/t3';
create table t2(a int) engine=federated connection='mysql://root@localhost:0/test/t3';

Suggested fix:
Do not make a copy of socket path.

Thank you for a problem report. Sorry, but where is the problem:

openxs@suse:~/dbs/5.0> bin/mysql -uroot test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.0.60-valgrind-max-debug Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> create table t1(a int) engine=federated connection='mysql://root@localhost/test/t3';
Query OK, 0 rows affected (0.01 sec)

mysql> create table t2(a int) engine=federated connection='mysql://root@localhost:0/test/t3';
Query OK, 0 rows affected (0.01 sec)

mysql> exit
Bye
openxs@suse:~/dbs/5.0> tail var/suse.err
080323 14:34:57  mysqld started
080323 14:34:58  InnoDB: Started; log sequence number 0 43655
080323 14:34:58 [Note] /home/openxs/dbs/5.0/libexec/mysqld: ready for connections.
Version: '5.0.60-valgrind-max-debug'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution

Do I miss something?

Hi Valeriy,

afaics (not sure) you didn't run mysqld under valgrind. It is easier to repeat using mysql-test-run script:
cd mysql-test; ./mysql-test-run --valgrind AAA
(where AAA is provided test case)

cat var/log/master.err
...
==17359== 88 bytes in 2 blocks are still reachable in loss record 4 of 6
==17359==    at 0x4005400: malloc (vg_replace_malloc.c:149)
==17359==    by 0x858664F: _mymalloc (safemalloc.c:137)
==17359==    by 0x8587753: _my_strdup (safemalloc.c:520)
==17359==    by 0x83E3F33: parse_url(st_federated_share*, st_table*, unsigned) (ha_federated.cc:659)
==17359==    by 0x83E407B: ha_federated::create(char const*, st_table*, st_ha_create_information*) (ha_federated.cc:2805)
==17359==    by 0x832021E: ha_create_table(char const*, st_ha_create_information*, bool) (handler.cc:2256)
==17359==    by 0x82FD0F4: rea_create_table(THD*, char*, char const*, char const*, st_ha_create_information*, List<create_field>&, unsigned, st_key*) (unireg.cc:298)
==17359==    by 0x836083F: mysql_create_table(THD*, char const*, char const*, st_ha_create_information*, Alter_info*, bool, unsigned) (sql_table.cc:1798)
==17359==    by 0x82427F6: mysql_execute_command(THD*) (sql_parse.cc:3177)
==17359==    by 0x82499FD: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:6173)
==17359==    by 0x824C247: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1875)
==17359==    by 0x824D794: do_command(THD*) (sql_parse.cc:1581)
==17359==    by 0x824E96E: handle_one_connection (sql_parse.cc:1187)
==17359==    by 0xC4B3DA: start_thread (in /lib/libpthread-2.5.so)
==17359==    by 0xBA506D: clone (in /lib/libc-2.5.so)
...

Verified just as described in the last comment. I've got:

==22755== 32 bytes in 2 blocks are definitely lost in loss record 4 of 7
==22755==    at 0x401C4CE: malloc (vg_replace_malloc.c:149)
==22755==    by 0x84B9219: my_malloc (my_malloc.c:34)
==22755==    by 0x84B93F3: my_strdup (my_malloc.c:79)
==22755==    by 0x8364F5A: parse_url(st_federated_share*, st_table*, unsigned) (ha_federated.cc:652)
==22755==    by 0x8369FE0: ha_federated::create(char const*, st_table*, st_ha_create_information*) (ha_federated.cc:2782)
==22755==    by 0x82BD7FA: ha_create_table(char const*, st_ha_create_information*, bool) (handler.cc:2256)
==22755==    by 0x829C624: rea_create_table(THD*, char*, char const*, char const*, st_ha_create_information*, List<create_field>&, unsigned, st_key*) (unireg.cc:298)
==22755==    by 0x82F0962: mysql_create_table(THD*, char const*, char const*, st_ha_create_information*, Alter_info*, bool, unsigned) (sql_table.cc:1798)
==22755==    by 0x81FE6D6: mysql_execute_command(THD*) (sql_parse.cc:3175)
==22755==    by 0x8205CC8: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:6173)
==22755==    by 0x81FBAFA: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1875)
==22755==    by 0x81FB18C: do_command(THD*) (sql_parse.cc:1581)
==22755==    by 0x81FA262: handle_one_connection (sql_parse.cc:1187)
==22755==    by 0x4057AA6: (within /lib/tls/libpthread.so.0)
==22755==    by 0x4188C2D: clone (in /lib/tls/libc.so.6)

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/44373

ChangeSet@1.2600, 2008-03-25 12:47:57+04:00, svoj@mysql.com +2 -0
  BUG#35509 - Federated leaks memory when connecting to
              localhost/default port
  
  When creating federated table that points to unspecified host or
  localhost on unspecified port or port is 0, small memory leak occurs.
  
  This happens because we make a copy of unix socket path, which is
  never freed.
  
  With this fix we do not make a copy of unix socket path, instead
  share->socket points to MYSQL_UNIX_ADDR constant directly.
  
  This fix is covered by a test case for BUG34788.
  
  Affects 5.0 only.

Approved. See comments in email.

Pushed into 5.1.24-rc

Pushed into 5.0.60

Pushed into 6.0.5-alpha

Noted in 5.0.60 changelog.

There was a memory leak when connecting to a FEDERATED table using a
connection string that had a host value of localhost or omitted the
host and a port value of 0 or omitted the port.