posted 08-08-2002 10:03 AM         

quote:

---

Originally posted by aelana:
Is there a way to test for memory leak for executable applications?

---

posted 08-08-2002 10:03 AM         

John

posted 08-08-2002 11:06 AM         

The key will be to launch/execute/then close over and over while monitoring memory with as little else going on as possible.

posted 08-08-2002 03:32 PM         

quote:

---

Originally posted by aelana:
So how will I know that there's a leaking problem?

---

So in the Task Manager, check out all the info regarding Memory. Write down the numbers before you run your test(s). Do a few iterations or test runs then check those Memory info again and compare with the original numbers you saw before running your test. If there's a Memory Leak, you should see, for example, that MEM Usage is higher or much higher than before. If there's no Memory Leak problem, the numbers you see before and after running and closing your application should be the same.
(If you have an old old copy of MS Excel, v1.0 i guess, you can see this Memory Leak problem very easily by simply running and closing it.)

posted 08-08-2002 03:32 PM         

If you have access to a developer/systems administrator, they should be able to show you how to monitor memory on a windows machined and determine if there are indications of a memory leak.

posted 08-08-2002 04:17 PM         

Memory leak testing in windows is a complex operation. Firstly you will have to decide how many configurations and service pack variations you need to cover. The fewer the better.

The next issue you will have to deal with is caching as this will at best cause transient memory effects. To cancel these out you may have to open and close an application several times.

The next complication is that various versions/configurations are in fact leaky by itself and you may need to test this in abscence of the target application.

Initially you will need to test for memory leaks in a standalone fashion and then with other applications running, switching between them.

Also if you application uses a comm stack you will need to test connections and disconnections for leaks.

The simplest method I use is coming up wth the most commonly used configuration and do a cycle test (Automated) of opening the target software, using it and then closing it. Reapeat this 50-100 times in a row and see if windows crashes or shows significant leaks. If it survives this then I start looking at other tests.

------------------
Robert Tehve
rtehve@bigpond.com

posted 08-08-2002 09:58 PM         

Here's some information from the MSDN collection:

CMemoryState provides a convenient way to detect memory leaks in your program. A "memory leak" occurs when memory for an object is allocated on the heap but not deallocated when it is no longer required. Such memory leaks can eventually lead to out-of-memory errors. There are several ways to allocate and deallocate memory in your program:

Using the malloc/free family of functions from the run-time library.
Using the Windows API memory management functions, LocalAlloc/LocalFree and GlobalAlloc/GlobalFree.
Using the C++ new and delete operators.
The CMemoryState diagnostics only help detect memory leaks caused when memory allocated using the new operator is not deallocated using delete. The other two groups of memory-management functions are for non-C++ programs, and mixing them with new and delete in the same program is not recommended. An additional macro, DEBUG_NEW, is provided to replace the new operator when you need file and line-number tracking of memory allocations. DEBUG_NEW is used whenever you would normally use the new operator.