Re: Valgrind, MySQL - a single query mem check

[Patrick Lau]

The flag works!

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?

Thanks,
Patrick

On Mon, Mar 16, 2009 at 5:25 PM, Ivan Novick <ivan@stripped> wrote:
>> -----Original Message-----
>> From: Patrick Lau [mailto:patro02@stripped]
>  > LEAK SUMMARY:
>> ==30826==    definitely lost: 2,828,751 bytes in 117,812 blocks.
>> ==30826==    indirectly lost: 2,619,022 bytes in 75,051 blocks.
>> ==30826==      possibly lost: 2,012 bytes in 72 blocks.
>> ==30826==    still reachable: 3,058,698 bytes in 93,895 blocks.
>> ==30826==         suppressed: 0 bytes in 0 blocks.
>>
>> ~2MB definitely lost... not the number I expected...
>>
>> I think LEAK SUMMARY is about the whole process... Is there a way to
>> check mem consumption of a query thread using valgrind? How would you
>> handle such a case?
>
> I find this pretty hard to believe, as I have run Valgrind myself on mysql
> and not seen any significant leaks like you are showing. Yes, LEAK SUMMARY
> will be for the entire mysqld process.  Valgrind will not break down the
> numbers per thread.  You can add the --leak-check=full and
> --show-reachable=yes options to see the details of the leaks found.  Also be
> sure to do a proper shutdown of the server and not some sort of irregular
> exit.
>
> Finally if you are seeing reproducible memory leaks, try to simplify the
> test case that produces the leak as much as possible and share the test case
> (SQLs) that you use to produce the leaks.
>
> Regards,
> Ivan Novick
>
>