From: Ivan Novick
Date: March 16 2009 4:25pm
Subject: RE: Valgrind, MySQL - a single query mem check
List-Archive: http://lists.mysql.com/internals/36394
Message-Id: <000501c9a653$dc0521b0$940f6510$@com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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