tag 615613 +wontfix severity 615613 minor thanks I attach some notes I made on trying to reproduce this. Basically all but the last one is just a matter of not freeing up the memory when you should. This is C not C++ or Java and you are entirely responsible or memory management.
On the stubborn 73,000 bytes or so I concur. These appear to be some MySQL start up overhead. In my furtehr experiments they seemed fairly stable so there is no evidence that this would actually lead to run away memory loss.
1.) first test ==3439== LEAK SUMMARY: ==3439== definitely lost: 964 bytes in 1 blocks ==3439== indirectly lost: 25,100 bytes in 8 blocks ==3439== possibly lost: 0 bytes in 0 blocks ==3439== still reachable: 73,900 bytes in 22 blocks ==3439== suppressed: 0 bytes in 0 blocks I know from debugging the 964 is the MYSQL structure. 2.) second test ==3487== LEAK SUMMARY: ==3487== definitely lost: 0 bytes in 0 blocks ==3487== indirectly lost: 0 bytes in 0 blocks ==3487== possibly lost: 0 bytes in 0 blocks ==3487== still reachable: 73,900 bytes in 22 blocks ==3487== suppressed: 0 bytes in 0 blocks 3.) third test ==3813== LEAK SUMMARY: ==3813== definitely lost: 1,920 bytes in 20 blocks ==3813== indirectly lost: 311,352 bytes in 58 blocks ==3813== possibly lost: 16,328 bytes in 2 blocks ==3813== still reachable: 73,900 bytes in 22 blocks ==3813== suppressed: 0 bytes in 0 blocks 4.) fourth test ==3841== LEAK SUMMARY: ==3841== definitely lost: 0 bytes in 0 blocks ==3841== indirectly lost: 0 bytes in 0 blocks ==3841== possibly lost: 0 bytes in 0 blocks ==3841== still reachable: 73,900 bytes in 22 blocks ==3841== suppressed: 0 bytes in 0 blocks
