List:Internals« Previous MessageNext Message »
From:Patrick Lau Date:March 16 2009 11:16pm
Subject:Re: Valgrind, MySQL - a single query mem check
View as plain text  
I know what you mean. Thanks.

But my mysqld is built with the config option --without-query-cache...

Is it really the query cache or can it also be our own stuff allocated
with my_malloc?

To be more precise we are looking for memory blocks which are not
freed after a query execution since after every query execution the
process mysqld grows and grows and also for memory leaks. Thats why we
are still interested in "still reachable" blocks.

Sorry for the misunderstanding. Thanks for your help!

Patrick

On Mon, Mar 16, 2009 at 9:33 PM, Kristian Nielsen
<knielsen@stripped> wrote:
> 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.
>
Thread
Valgrind, MySQL - a single query mem checkPatrick Lau16 Mar
  • Re: Valgrind, MySQL - a single query mem checkKristian Nielsen16 Mar
  • RE: Valgrind, MySQL - a single query mem checkIvan Novick16 Mar
    • Re: Valgrind, MySQL - a single query mem checkPatrick Lau16 Mar
      • Re: Valgrind, MySQL - a single query mem checkKristian Nielsen16 Mar
        • Re: Valgrind, MySQL - a single query mem checkPatrick Lau17 Mar
          • Re: Valgrind, MySQL - a single query mem checkJocelyn Fournier17 Mar
          • Re: Valgrind, MySQL - a single query mem checkKristian Nielsen17 Mar
  • Re: Valgrind, MySQL - a single query mem checkStewart Smith17 Mar
    • Re: Valgrind, MySQL - a single query mem checkPatrick Lau17 Mar