| 2016-02-18 21:31:20 |
Phil Sweeney |
description |
in ha_tokudb_admin.cc, tokudb::analyze::standard_t::analyze_key(), TokuDB does:
DBT key, prev_key;
...
error = cursor->c_get(cursor, &key, 0, _scan_direction);
...
if (key.data) tokudb::memory::free(key.data);
tokudb::memory::free is server's my_free(), but the key is allocated in PerconaFT/portability/memory.cc using os_malloc(), that is plain malloc().
This is a major no-no, mixing memory allocators. In MariaDB this causes safemalloc warnings in debug builds and crashes because memory accounting doesn't add up. In MySQL 5.7, I suspect, it will break memory related performance schema tables.
A possible fix could be to use toku_set_func_malloc()/etc functions from <portability/memory.h>, but that causes crashes elsewhere. May be not all PerconaFT code is ready for that (currently toku_set_func_malloc()/etc functionality is unused). |
in ha_tokudb_admin.cc, tokudb::analyze::standard_t::analyze_key(), TokuDB does:
DBT key, prev_key;
...
error = cursor->c_get(cursor, &key, 0, _scan_direction);
...
if (key.data) tokudb::memory::free(key.data);
tokudb::memory::free is server's my_free(), but the key is allocated in PerconaFT/portability/memory.cc using os_malloc(), that is plain malloc().
This is a major no-no, mixing memory allocators. In MariaDB this causes safemalloc warnings in debug builds and crashes because memory accounting doesn't add up. In MySQL 5.7, I suspect, it will break memory related performance schema tables.
A possible fix could be to use toku_set_func_malloc()/etc functions from <portability/memory.h>, but that causes crashes elsewhere. May be not all PerconaFT code is ready for that (currently toku_set_func_malloc()/etc functionality is unused). |
|
