Re: Valgrind, MySQL - a single query mem check

[Kristian Nielsen]

Patrick Lau <patro02@stripped> writes:

> Unfortunately there is a memory leak in our code. Running the same
> query several times increases the memory consumption of mysqld: in
> Megabytes (9, 23, 90, 90, 90 ...)

Is this in stock MySQL code (do you have a test case/query to show)? Or is it
only with your private modifications of the source?

> I'm trying valgrind to detect the leak, but it gives me this....
>
> 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...

That shows 8.5 mb leaked, not 2 ...

Also note that the Valgrind numbers are memory returned by malloc(). The
process size you see from `top` etc. is memory given by the kernel to the libc
malloc() pool, and that will usually be somewhat bigger, as libc will request
memory from the kernel in bigger batches.

> 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?

You could try using the macro VALGRIND_DO_LEAK_CHECK (from memcheck.h) in an
appropriate place in the code.

I haven't tried it myself, but if you call it after running each query, you
should get multiple reports, and you can use the delta between them to see the
effect of a single query. Note that "still reachable" will likely be much
higher, as some memory is not de-allocated until mysqld exit.

Hope this helps,

 - Kristian.