Practice 8. Zero Tolerance for Memory and Resource Leaks If you develop in a programming language or environment where memory or resource leaks are possible, you must have zero tolerance for leaks. Resource leaks lead to unpredictable behavior such as program crashes, and they can also be exploited by hackers to compromise your customer's computers. I wish it were possible to say that this is an easy practice to follow. Unfortunately, the reality is that even if you use available tools (see Chapter 5 on Defect Prevention), leaks can still happen. Sometimes, lower level APIs that your application uses leak memory. There isn't much you can do about those except to report the problem to the vendor. And while it might seem ideal to adopt a policy where you always free every allocated resource, sometimes you can't. The most frustrating example is if you have a large application that allocates large amounts of memory. Because operating systems don't provide a fast exit path for applications, if you were to explicitly free up all allocated memory when the application stops, it may take many seconds for the application to actually go away, which can be frustrating to users. Therefore, to get the appearance of a fast exit, it is common practice to not bother freeing up memory at all, quit, and let the operating system worry about it. This wouldn't be a problem except that when you use a memory leak detection tool, all of the memory and resources that were not explicitly freed on exit are reported as leaks, which makes legitimate leaks virtually impossible to detect…! All I can advise is to at least make sure you exercise due diligencedon't just ignore trying to find leaks. The tools available today have APIs that you can hook up to your application to start and stop leak detection. These can be very useful. No Memory Leak Can Be Ignored A common misconception about memory leaks is that only the big ones matter. Unfortunately, this is not true; a leak as small as one byte of memory is enough to set up a fence in the application's memory pool that will ensure the system cannot reuse that memory. One of my favorite examples of this problem happened a few years ago… I had just started at a company working on a product developed in C++ where it turned out the team had been very lax about memory leaks. Less than a month into the job I absent-mindedly left the application running at the end of the workday. When I came in the next morning, I discovered that the application had crashed sometime during the night. I wasn't sure it was a problem, thinking that perhaps the crash was caused by backups or some such thing, so that night I left it run- ning again with the same result. Curious, I then wrote a simple script to monitor the system memory (using a system call) so I could log memory usage while running the application. What I discovered was normal memory usage in the form of spikes as the program allocated and properly freed up large chunks of memory, but overall the memory consumed increased at a constant pace. The culprit turned out to be a very small leak of 4 bytes that unfortunately was happening every time the cursor blinked! Our users had been complaining that they had to constantly save their work because the application crashed at unpredictable times (sometimes unfortunately during a save operation). Once we understood the number of leaks in the product, we undertook a concerted effort to remove the leaks and released a version of the software with no new features, just all the leaks fixed. I insisted we do this despite the braying of our marketing department. That release was one of the most satisfying releases I have ever done, because our customers gave the release rave reviews and applauded us for not adding features and just fixing their major complaintstability. And after another release, our marketing department realized that although they hadn't been able to say anything new about the product, their job was now much easier because we had gained a reputation of listening to our customers, which is very powerful marketing indeed. |
|
