Bug #48937 | Memory leak from mysql_insert during partition pruning test | ||
---|---|---|---|
Submitted: | 20 Nov 2009 9:44 | Modified: | 27 Feb 2010 9:53 |
Reporter: | John Embretsen | Email Updates: | |
Status: | Can't repeat | Impact on me: | |
Category: | MySQL Server: Partitions | Severity: | S3 (Non-critical) |
Version: | 5.6.0-beta | OS: | Linux (32-bit) |
Assigned to: | Mattias Jonsson | CPU Architecture: | Any |
Tags: | valgrind |
[20 Nov 2009 9:44]
John Embretsen
[20 Nov 2009 10:41]
Sveta Smirnova
Thank you for the report. Where is runall.pl located now? I can not find it in latest update of mysql-test-extra-6.0
[20 Nov 2009 11:28]
John Embretsen
runall.pl is currently in the default randgen repository on Launchpad, which you get by doing: bzr branch lp:randgen P.S I just ran the test again on a 64-bit linux platform and did not see this issue... I'll try to repeat.
[20 Nov 2009 20:30]
Sveta Smirnova
Can not repeat on 64-bit Linux too.
[22 Nov 2009 14:54]
John Embretsen
I was able to repeat on 32-bit Linux only. Build info: CC='gcc' CFLAGS='-g -DSAFE_MUTEX -g -DHAVE_purify -Wall -DUNIV_LINUX' CXX='g++' CXXFLAGS='-g -DSAFE_MUTEX -g -DHAVE_purify -Wall -fno-implicit-templates -fno-exceptions -fno-rtti' LDFLAGS='-g -rdynamic ' ASFLAGS='-g' ./configure '--enable-thread-safe-client' '--enable-local-infile' '--with-pic' '--with-client-ldflags=-static' '--with-mysqld-ldflags=-static' '--with-zlib-dir=bundled' '--without-ndb-debug' '--with-big-tables' '--with-ssl' '--with-readline' '--with-embedded-server' '--with-archive-storage-engine' '--with-blackhole-storage-engine' '--with-csv-storage-engine' '--with-example-storage-engine' '--with-federated-storage-engine' '--with-partition' '--with-extra-charsets=all' '--with-innodb' '--with-ndbcluster' '--with-debug' '--with-libevent' (flags and options taken from Pushbuild logs for the corresponding platform)
[22 Nov 2009 20:21]
MySQL Verification Team
I couldn't repeat on Ubuntu 9.10 64-bit.
[25 Nov 2009 12:43]
Sveta Smirnova
Thank you for the report. Verified as described: =20165== 151,296 bytes in 16 blocks are possibly lost in loss record 34 of 37 ==20165== at 0x40051F9: malloc (vg_replace_malloc.c:149) ==20165== by 0x867BFAE: my_malloc (my_malloc.c:34) ==20165== by 0x867C22D: my_realloc (my_realloc.c:44) ==20165== by 0x858650C: mi_alloc_rec_buff (mi_open.c:728) ==20165== by 0x858613B: mi_open (mi_open.c:643) ==20165== by 0x8580248: ha_myisam::open(char const*, int, unsigned) (ha_myisam.cc:699) ==20165== by 0x839CD11: handler::ha_open(TABLE*, char const*, int, int) (handler.cc:2133) ==20165== by 0x83A7440: ha_partition::open(char const*, int, unsigned) (ha_partition.cc:2560) ==20165== by 0x839CD11: handler::ha_open(TABLE*, char const*, int, int) (handler.cc:2133) ==20165== by 0x82E9315: open_table_from_share(THD*, TABLE_SHARE*, char const*, unsigned, unsigned, unsigned, TABLE*, bool) (table.cc:1886) ==20165== by 0x82DB45F: open_unireg_entry(THD*, TABLE*, TABLE_LIST*, char const*, char*, unsigned, st_mem_root*, unsigned) (sql_base.cc:3921) ==20165== by 0x82D969A: open_table(THD*, TABLE_LIST*, st_mem_root*, bool*, unsigned) (sql_base.cc:2922) ==20165== by 0x82DC3D5: open_tables(THD*, TABLE_LIST**, unsigned*, unsigned) (sql_base.cc:4588) ==20165== by 0x82DCD5C: open_and_lock_tables_derived(THD*, TABLE_LIST*, bool) (sql_base.cc:4994) ==20165== by 0x829F365: open_and_lock_tables(THD*, TABLE_LIST*) (mysql_priv.h:1499) ==20165== by 0x82999BB: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:5110) ==20165== To repeat one should compile MySQL server with options provided.
[2 Dec 2009 7:22]
Sveta Smirnova
Test partition_pruning uses LIST COLUMNS which is not applicable to 5.1
[24 Feb 2010 16:52]
Mattias Jonsson
I have tested with a later mysql-next-mr-bugteam (fedora 12 32-bit, li-bing.song@sun.com-20100131133741-6jwl1n50aemwqx51), without succeeding repeating this. John or Sveta, Could you please help me repeat this with a later mysql-next-mr (or possibly mysql-trunk) again?
[27 Feb 2010 9:53]
John Embretsen
I had some issues running the test to completion with valgrind (it kept timing out), but once I had that taken care of I was not able to repeat with the mysql-next-mr-bugfixing branch as of yesterday. Setting status to "Can't repeat". I will re-open the bug if I see it again (others can do the same), however, note that this version of the test (valgrind, 32-bit linux) is not running on an automatic basis (Pushbuild), so manual testing will be required to detect it. 64-bit linux valgrind runs of this test are set up in Pushbuild for mysql-next-mr (weekly), and this issue has not been seen there as far as I know.