This error is common for PC programmers who experiment with various memory models (I personally cause this error annually whether I need to or not). Symptoms of this error include a call to malloc that hangs the program, or the program runs to completion but DOS cannot be reloaded because the program trashed some system memory, such as the interrupt vector.

This error can be especially annoying because the same program may run without a hitch using other compilers or memory models. Again the inexperienced programmer may blame the compiler, the runtime or some other library, and sometimes even the hardware. The fallacious proof for these indictments is that the program runs fine elsewhere.

The cure is to include an external definition for the heap routines in a system header file. Unfortunately the name of the system file may vary from compiler to compiler. stdlib.h contains the external definitions for ANSI C. Other environments might include definitions in alloc.h, malloc.h or even stdio.h.

Including the appropriate file with the declaration is preferable to simply externally declaring the functions in the code. Usually, including the system definitions will not cause type conflicts with the actual function in the library. Some compilers define malloc as returning a character pointer (i.e., char *), while others define it as returning a void pointer (i.e., void *). Strict type checking notifies the programmer when he or she forgets to declare malloc. However, a programmer can experience hours of aggravation if he or she declares the function differently from the runtime library definition and the compiler enforces strict type checking.

When a program on a PC runs out of memory, malloc will generally return a NULL pointer. If the programmer did not bother to check the malloc return value for NULL, the program will probably step on the interrupt vector in low memory and eventually cause the machine to hang. Experienced programmers recognize that identifying bug locality is worth the additional effort required to check return codes from library routines such as malloc. On a machine with virtual memory, this type of memory leakage has a different symptom. As the program continues to run, it chews up virtual memory until the swap space is full. One can discern this situation by an inordinate amount of I/O activity. Increased I/O slows the program to a glacial grind. If the program continues, it also will eventually return a NULL from malloc. On most virtual memory machines, if the program does not check the return value from malloc, the program will dereference the NULL pointer and cause an access violation.

Sound program design will prevent memory leakage errors. Generally, you should allocate and deallocate memory at the same level in a program.

Using an uninitialized pointer in a PC program can have drastic effects. Since there is generally no memory protection, wild pointers let a programmer step on program and system memory. Wild pointers can corrupt areas of memory containing program code, the system configuration, and even the current date and time.

On machines with memory protection, this error commonly results in an access violation. But when, by chance, the uninitialized pointer points to a valid memory address, the symptoms are similar to those observed when dereferencing a deallocated memory section (i.e., data item values mysteriously change). The previously discussed magic numbers are an effective means of debugging programs.

Symptoms are similar to those seen when inadvertently freeing the same location more than once. The next call to malloc may result in an access violation, a NULL pointer assignment or even in malloc hanging in an infinite loop.

Some more intelligent implementations of free use a hidden magic number to verify that the pointer originated from malloc. If the pointer was never malloced, free prints a message and returns, or even exits. This seems the exception (no pun intended) rather than the rule since additional checking adds unavoidable overhead.

Using a housekeeping layer is also an effective way to shoot these bugs. The malloc/free housekeeping layer helps the program recognize that it has not allocated a particular address. The housekeeping layer then raises an exception.