Hello friends!
I guess my question is not really tough: How would you test your code for having or not having memory leaks? Do you have any methods or customs for this purpose? I guess monitoring the memory usage of my code's process could do the job... Please give some ideas, thanks!
Greets, Gábor
Checking that every memory allocation also has a matching 'free' will catch most leaks - this can be done automatically through using the memory function indirectly and keeping a list of currently allocated blocks (then remove them when they're free'd) and check at exitprocess if the list is empty.
The problem is that there are also indirect allocations (e.g. GDI memory) which are a little harder to track.
My own habit is to always write the call to free the memory at the same time I write the call to allocate it - then you don't forget to do it :wink
Gabor,
I use the same technique as Tedd but if I am writing something very messy and complicated, i tend to write a test piece, put the procedure into it and run it a few million times to see if it effects the system memory. You find a memory leak reasonably quickly that way.
Hi Gabor
You can take a look at the ResGuard I implemented for ObjAsm32. It monitors all APIs listed in the IAT and checks for their return value and if there is a matching API to free a resource. This tool is similar to MemProof but can be extended to check more APIs as required.
I know that it requires advanced techniques, but it's worth to take a look at it.
Regards,
Biterider
There are some tools about that do it, like Valgrind and others.
However, nothing really beats the approach Tedd and Hutch mentioned.
Nice to see you post BiteRider.
hello,
the Windows Resource Kits as a tool that made that when the prog is debugged.
ToutEnMasm
Hello!
Thanks for the replies. I guess for me the best approach is that of Hutch. I use many "indirect" memory allocations, dynamically created objects allocating other objects or arrays... I guess it would be too much effort to track down every allocation and free calls. Of course the other ideas are also to be considered :)
Thanks again and
Greets, Gábor
The only problem with Hutch's approach is that it generally won't identify the culprit, especially if you have a complicated system. It will assure you that everything is okay, but can't do the entire job.
Debug strings for allocation/deallocations may be the easiest way (after checking), since then you will have a text file showing the results of an execution.
Cheers,
Zooba :U
Hi Gabor,
I simply would check for how much free memory there is at the very start of your program, save the amount of free memory in a variable.
At exit point, just before returning to OS, check free memory again, and compare with the first saved variable.
Is there difference, then you have a memory leak.
But beware to exit processes which could allocate and free memory during the run of your program (like internet browsers).
See you!
Erik de Keijzer
The Netherlands
(the c64emu programmer)
:)
edkedk: that might work if there is a HUGE leak, but there are other programs running which will also allocate memory, and you cannot control this. So the os memory available at the start and end of your program will NOT be the same, and this does not indicate a memory leak for your program.
A related idea -- check the memory footprint of your program (VirtualQuery?) at startup, then again at exit.
[assuming this isn't the same as you meant edkedk :bdg]