Sample code for TestForMemoryLeak.
long GetAvailMemory()
{
MEMORYSTATUS stat;
GlobalMemoryStatus (&stat);
return stat.dwAvailPhys;
},
test()
{
int mem = GetAvailMemory(); // get initial amount of memory
char* x = new char[5]; // allocate some memory (MarkSchumann says try new char[500000])
x[4] = 0; // added this line
assert( mem != GetAvailMemory() ); // make sure we allocated (FAILS)
delete x; // free the mem
assert( mem == GetAvailMemory() ); // should be back at what we started
},
I'd be interested in seeing what the compiler has done to this under the covers. It seems likely to me that the optimizer has stripped out lines 2 and 4, as the variable is never used.
I think maybe the GetAvailMemory() function isn't returning what I want it to. Is there any function in windows that returns the amount of memory used by a process?
You're on the right track. I don't think it's guaranteed that GetAvailMemory() is granular to the degree you expect. Just for fun and games, consider the change I suggest in your test() function above. Betcha that shows some change.
In classic MS-DOS, the system doles out memory in multiples of 16 bytes, but I don't know how Win98 does it. Note that "new char" doesn't hit the OS directly; it uses the compiler-supplied runtime library to buffer that request. You probably made a request that happened to be satisfied from the buffers managed by that runtime library. --MarkSchumann
(Someone, perhaps the original poster, wrote:) comments, i put in new char[5000] and this causes some new memory to be allocated
Okay then, I think that answers it. When you allocate about 5 Kbytes in this circumstance, the runtime library has to make a call to the operating system to get that memory, thereby decrementing the counter returned by GetAvailMemory(). When you allocate merely 5 bytes, that O/S call is (usually) unneeded, hence no change in GetAvailMemory().
If you are using GetAvailMemory() as a way to count every single byte your application is using via new, it won't work. For that purpose you might prefer a custom "new" handler. --MarkSchumann
Alternately, one could just overload the malloc,free, new, and delete functions - Then track each call either with a running counter, or per pointer(it helps if you record the caller's __FILE__ and ___LINE__)
The MSVCRT (MiscroSoft Visual C runtime), if you're using visual studio, has great memory leak detection support, including dumping leaks, inspecting the heap, and (niftily) breaking into the debugger on specific allocations. This technique can help you detect a memory leak but is not especially usefull for figuring out where the leak is. --ChrisMellon.