Bug #45164 Agent memory leak for connection failures
Submitted: 28 May 2009 15:45 Modified: 25 Jun 2009 10:36
Reporter: Matthew Lord Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Enterprise Monitor: Agent Severity:S2 (Serious)
Version:2.0.x (I used 2.0.5.7153) OS:Any
Assigned to: Jan Kneschke CPU Architecture:Any
Tags: Agent, memory leak

[28 May 2009 15:45] Matthew Lord
Description:
We seem to have a small memory leak that occurs when a connection attempt
to the dashboard fails.  This poses a problem if the agent is unable to 
connect to the dashboard for a very long period of time.

How to repeat:
I did some valgrind tests, here are the results:

After letting the agent run for a couple of
minutes:

==11013== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 85 from 4)
==11013== malloc/free: in use at exit: 515,630 bytes in 4,621 blocks.
==11013== malloc/free: 13,380 allocs, 8,759 frees, 3,282,656 bytes allocated.
==11013== For counts of detected errors, rerun with: -v
==11013== searching for pointers to 4,621 not-freed blocks.
==11013== checked 52,420,544 bytes.
==11013==
==11013== LEAK SUMMARY:
==11013== definitely lost: 112 bytes in 1 blocks.
==11013== possibly lost: 1,632 bytes in 6 blocks.
==11013== still reachable: 513,886 bytes in 4,614 blocks.
==11013== suppressed: 0 bytes in 0 blocks.

It looks like we lost 112 bytes. I then let it run for about twice as long:
==11012== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 50 from 3)
==11012== malloc/free: in use at exit: 9,565 bytes in 183 blocks.
==11012== malloc/free: 1,102 allocs, 919 frees, 104,219 bytes allocated.
==11012== For counts of detected errors, rerun with: -v
==11012== searching for pointers to 183 not-freed blocks.
==11012== checked 201,192 bytes.
==11012==
==11012== LEAK SUMMARY:
==11012== definitely lost: 292 bytes in 3 blocks.
==11012== possibly lost: 0 bytes in 0 blocks.
==11012== still reachable: 9,273 bytes in 180 blocks.
==11012== suppressed: 0 bytes in 0 blocks.

Looks like we have a pretty clear case of leaking some bytes with every
connection attempt failure.

-----------

After running for about 3 1/2 days we seem to have leaked
close to 34MB:
==11245== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 85 from 4)
==11245== malloc/free: in use at exit: 46,314 bytes in 224 blocks.
==11245== malloc/free: 16,570,499 allocs, 16,570,275 frees, 29,233,263,714 bytes allocated.
==11245== For counts of detected errors, rerun with: -v
==11245== searching for pointers to 224 not-freed blocks.
==11245== checked 203,792 bytes.
==11245==
==11245== LEAK SUMMARY:
==11245== definitely lost: 34,434 bytes in 39 blocks.
==11245== possibly lost: 0 bytes in 0 blocks.
==11245== still reachable: 11,880 bytes in 185 blocks.
==11245== suppressed: 0 bytes in 0 blocks.
==11245== Rerun with --leak-check=full to see details of leaked memory.
==11244==
==11244== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 50 from 3)
==11244== malloc/free: in use at exit: 9,565 bytes in 183 blocks.
==11244== malloc/free: 1,089 allocs, 906 frees, 103,061 bytes allocated.
==11244== For counts of detected errors, rerun with: -v
==11244== searching for pointers to 183 not-freed blocks.
==11244== checked 201,192 bytes.
==11244==
==11244== LEAK SUMMARY:
==11244== definitely lost: 292 bytes in 3 blocks.
==11244== possibly lost: 0 bytes in 0 blocks.
==11244== still reachable: 9,273 bytes in 180 blocks.
==11244== suppressed: 0 bytes in 0 blocks.
==11244== Rerun with --leak-check=full to see details of leaked memory.
[17 Jun 2009 21:09] Diego Medina
This memory leak does not happen on 2.1.0.1062
[19 Jun 2009 17:39] Diego Medina
This bug was fixed on the 2.1 agents.
Agent 2.1.0.1062 does not show the memory leak.
[25 Jun 2009 10:36] Tony Bedford
An entry was added to the 2.1.0 changelog:

A small memory leak occurred in the agent when a connection attempt to the dashboard failed. This represented a problem if the agent was unable to connect to the dashboard for a long period of time, as each failure to connect would leak some more memory.