From: Kristian Nielsen
Date: March 16 2009 8:33pm
Subject: Re: Valgrind, MySQL - a single query mem check
List-Archive: http://lists.mysql.com/internals/36398
Message-Id: <878wn55hsp.fsf@knielsen-hq.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Patrick Lau <patro02@stripped> writes:

> But now valgrind gives me this after a query execution (besides other
> notifications which are negligible wrt. the size).
>
> ==13045== 79,352,948 bytes in 607 blocks are still reachable in loss
> record 31 of 31
> ==13045==    at 0x4025D2E: malloc (vg_replace_malloc.c:207)
> ==13045==    by 0x84022C9: _mymalloc (safemalloc.c:137)
> ==13045==    by 0x820BC12: _ZL16create_key_cachePKcj (set_var.cc:3586)
> ==13045==    by 0x820BDDE: get_or_create_key_cache(char const*,
> unsigned) (set_var.cc:3620)
> ==13045==    by 0x81EB489: _ZL20mysql_init_variablesv (mysqld.cc:7089)
> ==13045==    by 0x81EFAD1: _ZL21init_common_variablesPKciPPcPS0_
> (mysqld.cc:2758)
> ==13045==    by 0x81F138F: main (mysqld.cc:3766)
>
> Where does this come from? Is this an automatism done by mysql or my own stuff?

Note the "are still reachable" message. When memory is not freed, but is still
reachable, it is possible (and in mysqld quite likely) that it will be freed
later during server shutdown. Therefore, when using VALGRIND_DO_LEAK_CHECK,
the "is still reachable" reports are probably not all that useful, and you
should probably run without --show-reachable.

On the other hand, "definitely lost" and "indirectly lost" from
VALGRIND_DO_LEAK_CHECK _do_ indicate a direct memory leak. As the pointer to
the memory is lost, the program will never be able to properly free the
memory. Usually "possibly lost" is the same.

For the particular report you quoted, my guess without looking deeper is that
it is the query cache that is allocated lazily when the first query is entered
into it. So not a leak.

Hope this helps,

 - Kristian.