Bug #41990 memory leak in mysqldump --all-databases
Submitted: 9 Jan 2009 8:11
Reporter: Shane Bester (Platinum Quality Contributor) Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: mysqldump Command-line Client Severity:S3 (Non-critical)
Version:5.1.30 OS:Any
Assigned to: CPU Architecture:Any
Tags: memory leak
Triage: Triaged: D3 (Medium)

[9 Jan 2009 8:11] Shane Bester
Description:
==20321== 26,624 bytes in 1 blocks are definitely lost in loss record 4 of 4
==20321==    at 0x40054FB: realloc (vg_replace_malloc.c:306)
==20321==    by 0x80EA1EF: my_realloc (my_realloc.c:62)
==20321==    by 0x808A2D6: dynstr_realloc (string.c:84)
==20321==    by 0x807C159: dump_table (mysqldump.c:4966)
==20321==    by 0x807CA3C: dump_all_tables_in_db (mysqldump.c:4025)
==20321==    by 0x807DC64: main (mysqldump.c:3813)

==20321== LEAK SUMMARY:
==20321==    definitely lost: 26,716 bytes in 2 blocks.
==20321==    indirectly lost: 16,384 bytes in 3 blocks.
==20321==      possibly lost: 0 bytes in 0 blocks.
==20321==    still reachable: 14 bytes in 1 blocks.
==20321==         suppressed: 0 bytes in 0 blocks.

How to repeat:
valgrind --tool=memcheck   --leak-check=yes -v --show-reachable=yes  ./mysqldump -uroot --all-databases

only database I had was empty `test` database and the standard `mysql` database.

Suggested fix:
get rid of valgrind's "definitely lost" errors.
[9 Aug 2010 13:35] Steve Willett
Has this been fixed yet, if so please let me know which build?