Bug #41990 memory leak in mysqldump --all-databases

• Submitted: 9 Jan 2009 8:11
• Reporter: Shane Bester (Platinum Quality Contributor)
• Status: Verified
• Category: MySQL Server: mysqldump Command-line Client
• Severity: S3 (Non-critical)
• Version: 5.1.30
• OS: Any
• CPU Architecture: Any
• Tags: memory leak

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