Bug #53391 rpl_typeconv crashes (freeing slave_load_tmpdir)
Submitted: 3 May 2010 20:00 Modified: 4 May 2010 12:07
Reporter: Guilhem Bichot Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:6.0-codebase-bugfixing OS:Linux (64)
Assigned to: CPU Architecture:Any

[3 May 2010 20:00] Guilhem Bichot
Description:
I have alfranio.correia@sun.com-20100426092226-bnkzpjs8uqkl7l16 .
It's a repeatable crash. With --valgrind:

==13324== Invalid free() / delete / delete[]
==13324==    at 0x4C24D68: free (vg_replace_malloc.c:325)
==13324==    by 0xAD4AD1: my_no_flags_free (my_malloc.c:66)
==13324==    by 0x6E1A4D: clean_up(bool) (mysqld.cc:1585)
==13324==    by 0x6E1841: unireg_abort (mysqld.cc:1483)
==13324==    by 0x6E5BE8: init_server_components() (mysqld.cc:4356)
==13324==    by 0x6E66F3: mysqld_main(int, char**) (mysqld.cc:4964)
==13324==    by 0x6E02D3: main (main.cc:24)
==13324==  Address 0x63dc2fc is 44 bytes inside a block of size 54 free'd
==13324==    at 0x4C24D68: free (vg_replace_malloc.c:325)
==13324==    by 0xAD4AD1: my_no_flags_free (my_malloc.c:66)
==13324==    by 0xAC6C43: free_root (my_alloc.c:349)
==13324==    by 0xAC0776: free_defaults (default.c:580)
==13324==    by 0x6E1A34: clean_up(bool) (mysqld.cc:1582)
==13324==    by 0x6E1841: unireg_abort (mysqld.cc:1483)
==13324==    by 0x6E5BE8: init_server_components() (mysqld.cc:4356)
==13324==    by 0x6E66F3: mysqld_main(int, char**) (mysqld.cc:4964)

I just run
./mtr --mem rpl_typeconv 

slave_load_tmpdir is freed at mysqld.cc:1582 i.e.
  if (defaults_argv)
    free_defaults(defaults_argv);

and freed again at 1585:
  my_free(slave_load_tmpdir,MYF(MY_ALLOW_ZERO_PTR));
double free = segmentation fault.

How to repeat:
./mtr --mem rpl_typeconv 

Suggested fix:
In my case, the value of slave_load_tmpdir ("../../tmp") comes from a my.cnf file created by mtr. It is probably allocated by the options parsing code. It is logically freed by free_defaults(), so should not be freed again.
On the other hand, if it is not set in startup options, it's allocated:

  if (!slave_load_tmpdir)
  {
    if (!(slave_load_tmpdir = (char*) my_strdup(mysql_tmpdir, MYF(MY_FAE))))
and then it's logical to free it with x_free().
slave_load_tmpdir is a Sys_var_charptr, and looking at this class in sys_vars.h, it could be that:
* x_free() is unneeded (the destructor of the class will free if needed).
* the my_strdup() above should turn on the ALLOCATED flag, for the destructor to free.
* But that should be checked with Valgrind, including in other scenarios where the variable is modified at runtime with SET GLOBAL.
[4 May 2010 11:12] Sveta Smirnova
Thank you for the report.

I can not repeat described behavior. How did you compile mysqld? Which version of valgrind and OS you are using?
[4 May 2010 12:07] Guilhem Bichot
Linux 64 bit (ubuntu 9.10); valgrind 3.5.0-debian; built with
BUILD/compile-pentium64-valgrind-max.
Luis just pointed that this bug is a duplicate of BUG#51635.