Memory manager Debug mode

The memory manager supports a debug mode to help you deal withallocation problems. Debug mode can only be set if the heap is empty, meaning nomemory has been allocated in the heap. The simplest way to ensure debug mode is setfor the default main heap is to import the storage debug mode module as the firstimported file in the main program source file.

For Modula-2 the module name is

SetExStorageDebugMode

Example

IMPORT SetExStorageDebugMode;

For Ada95 the package name is

Sbs.SetStorageDebugMode

Example

with Sbs.SetStorageDebugMode;

Debug mode will detect on a deallocate, and raise an exceptionif

• You attempt to deallocate memory block more than once.
• You attempt to deallocate a NIL or null pointer.
• You attempt to deallocate memory into a heap from which it did not originate.
• You attempt to deallocate a different block size than was originally allocated for the block.
• The memory block was overwritten by some code.

Overwrite detection

For memory overwrite detection the memory manager allocates additionalmemory on each allocation and places a magic number in the memory locations immediatelybefore and after the memory block returned to you. Nothing should write to thesememory locations, and therefore if they are altered then some code somewhere is inerror. This detection is done on a deallocate procedure call. To help isolate theoffending code additional mechanisms exist for checking for memory overwrites.

ScanForMemoryOverwrites. This procedure does just this. If anoverwrite exists an exception is raised.

ScanForMemoryOverwritesOnApiCalls. This procedure will checkfor memory overwrites on all memory manager API calls, including allocate. An exceptionis raised if an overwrite occurs.

Leak detection

In debug mode additional overhead is allocated to support leakdetection. After your application "thinks" it has deallocated everythingyou can call CheckForMemoryLeaks. Any allocated memory blocks will be detected anda call back procedure of your will be called for each block. The allocation id numberof the memory block will be passed to the call back procedure. You use the leak detectionis in conjunction with the debugger. You use the allocation id number with the SetMemoryStopLeakCallbackAPI call. You set a breakpoint in the call back procedure associated with this APIcall. When the breakpoint is triggered the memory block that was leaked has justbeen allocated and you can then analyze and trace the source code of your programto determine why the memory was leaked.

You must have a repeatable execution of your program for leakdetection to function properly, otherwise the allocation ids will not be the samefrom run to run.

You can use this even with some memory still allocated but youwill have to filter out the legitimately allocated blocks from the leaks in yourown code.