RPC HELP DEBUG Memory Leaks
Memory Leaks
A good indication of a memory leak is when a running program is steadily decreasing the free pool of memory. As it runs or every time the program is started and stopped, free memory is steadily decreased.
Specifically, a program requests some bytes of memory from the Microsoft Windows operating system (OS). When the OS provides it, it marks those bytes as taken. The free pool of memory (i.e., unmarked bytes) is decreased. When the program is finished with the memory, it should return the memory back to the OS by calling the FREE or DISPOSE functions. This allows the OS to clear the "taken" status of that memory, thereby replenishing its free pool. When a programmer forgets to free the memory after use or the program fails before it has a chance to execute the code that frees the memory, the memory is not reclaimed.
At all times, the program should keep track of which memory it's using. It does this by storing "Handles" (i.e., memory addresses of the beginning byte of each memory block). Later, when freeing memory, the Handle is used to indicate which memory address to free. If the variable that holds such a Handle is overwritten, there is no way to determine the Handle.
Nine out of ten times, memory leakage can be traced back to the application code that requests memory and then forgets to return it or cannot clean up after a crash.
As common with other professional-level languages (e.g., C/C++), Delphi has constructs that applications can use to: request memory, type cast it, and return it. This requires developers to use their best judgement on how to best work with the system memory.
Avoiding memory leaks (and the often-subtle coding errors that lead to them) is a challenge for Delphi programmers, especially for those whose main experience is working with M.
The insidious effect of these leaks (e.g., gobbling up 1K of memory each time that a certain event occurs) makes them difficult to detect with normal program testing. By "normal testing" we mean exercising all the possible paths through the code once, a difficult enough process in a Microsoft Windows environment. Often, these leaks will result in a symptom only under peculiar conditions (e.g., several other applications are running, reducing system resources) or only after extended use of the application (e.g., Do you notice that Microsoft Windows problems crop up in the afternoon, even though you were doing the same thing that morning?).
The symptom that we are most likely to hear about from users is the following:
- "My computer was working fine until I installed the XYZ VistA software application on my PC. Now, it freezes up (gives me error message, says it's out of memory, etc.) all the time, even when I am not using the XYZ package. No, I can't duplicate it, it just happens!"
One of the reasons that there is an extensive market for automated testing tools for Microsoft Windows and client/server applications is that thorough testing is very difficult to do manually.
Fortunately, there are diagnostic products available for detecting code that will cause memory leaks. It will help programmers and code reviewers to find these leaks. Its use by people just starting out in Delphi programming will help them identify the situations that cause memory leaks. This can serve as a good learning experience for the new Delphi developer.
No application is immune from memory leaks, careful analysis of previous Broker code revealed some places where, under certain conditions, memory was not being released after it was used (i.e., memory leaks). These areas have been identified and corrected with this version of the Broker.
