Example—the Nortel Porting Project. There is a story (refer to the information box as follows) about how developers at Nortel (a large telecom and network equipment multinational corporation in Canada) had a very hard time debugging what turned out to be a memory leakage issue. The crux of it is this: when porting a Unix application to VxWorks, while testing it, they noticed a small 18-byte leak occurring, which would eventually cause the application to crash. Finding the source of the leak was a nightmare— reviewing the code endlessly provided no clues. Finally, the game changer proved to be the use of a leak detection tool (we'll cover this in the coming Chapter 6, Debugging Tools for Memory Issues). Within minutes, they uncovered the root cause of the leak: an innocent-looking API, inet_ntoa(3) (refer to the information box), which worked in the usual manner on Unix, and as well as in VxWorks. The catch: in the VxWorks implementation, it was allocating memory under the hood—which the caller was responsible for freeing! This fact was documented, but it was a porting project! Once this fact was realized, it was quickly fixed.

Some observations on programs with leakage bugs:

• The program behaves normally for a long, long while; suddenly, after, say, a month of uptime, it abruptly crashes.
• The root leakage could be very small—a few bytes at a time; but is probably invoked often.
• Attempting to find leakage bugs by carefully matching your  instances of malloc(3) and free(3) does not work; library API wrappers often allocate memory under the hood and expect the caller to free it.
• Leaks often escape unnoticed because they are inherently difficult to spot in large codebases, and once the process dies, the leaked memory is freed back to the system.

Bottom line:

• Do not assume anything
• Read the API documentation carefully
• Use tools (covered in the coming Chapter 6, Debugging Tools for Memory Issues)

One cannot overstate the importance of using tools to detect memory bugs!