List:Internals« Previous MessageNext Message »
From:Jocelyn Fournier Date:March 16 2009 11:45pm
Subject:Re: Valgrind, MySQL - a single query mem check
View as plain text  
Hi,

Instead of the query_cache, I would bet it's the key_cache, which is 
shared amoung all the threads. You can try to set the key_cache to 0 and 
see if the leak still occurs.

   Jocelyn

Le 17/03/2009 00:16, Patrick Lau a écrit :
> 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