Novell Home

NetWare 5 Memory Debugging Features

Novell Cool Solutions: Feature

Digg This - Slashdot This

Posted: 23 Jun 2000


The NetWare 5 operating system provides several new features that are helpful in debugging problems associated with allocated memory. Buffer overruns and freed memory accesses can now be detected in the actual act rather than eons after the deed has occurred. In addition, some commands have been added to the internal debugger to aid in dealing with NLM memory issues. Stack overrun detection has also been added.

Buffer overrun and freed memory access detection is accomplished by aligning the end of each allocated memory buffer with the end of a page boundary and positioning a guard page after the allocated memory. When a buffer overrun happens, a page fault abend occurs and the machine stops at the instruction that is reading or writing past the end of the buffer, even if the instruction is not found in the code segment of the NLM that owns the memory. When allocated memory is freed, the physical pages used for the memory allocation are unmapped. If an access to freed memory occurs, a page fault abend happens and the machine is stopped at the code location where the inappropriate read or write is located.

Buffer overruns and freed memory accesses can be detected by using one of the two new options that have been added to the console "load" command. Memory allocation debugging is enabled for a single NLM basis when the NLM is loaded. The first option performs the strictest check and has the following format:

    load -m nlmName

This is a strict check because the size of the allocation is the exact size requested by the caller.

The second option performs a more relaxed check and has the following format:

    load -r nlmName

This check is more relaxed because the size of the allocated buffer is the size that is normally granted. The normally granted size falls on specific size boundaries and usually ends up padding the requested size by a little bit.

The normally used allocation code is optimized for performance. By using one of the above mentioned load options, the allocation code for the specified NLM is replaced by alloction code that is optimized for debugging. By way of warning, the debug allocation code takes two or three times longer to allocate and free memory than the normal allocation code. Using the debug feature increases the amount of memory used for memory allocations substantially, but this is somewhat offset by the fact that the debug feature is on a per NLM basis and is not system wide.

The internal debugger has had several commands added that are useful for seeing overall memory usage, specific NLM memory usage, and individual allocations. This can be helpful in determining in the debugger how much allocated memory an NLM is using or in finding memory leaks.

The following debugger commands have been added:

    .MS Memory Summary displays information about how much memory is on the system and where it is being used.
    .MR Memory Resource Tag displays information about how many allocations and bytes are currently being tracked on memory allocation resource tags.
    .MT Memory Total displays information about the total amount of memory currently in an NLM's alloc pools. This is a sum of all memory resource tags associated with an NLM as well as available allocations and overhead in the alloc pools.
    .MO Memory Outstanding displays a list of all memory allocations that are currently in use by an NLM.

In addition, the ? debugger command has been enhanced to display as much information as possible when a query about an allocated memory address is made. This information includes the starting address of the allocated memory buffer, the size, the resource tag, logical equals physical mapping, logical not equals physical mapping, debug mode, corruption status, and so on.

Stack overrun detection is accomplished by using a technique similiar to the one used for detecting allocated memory buffer overruns. Instead of placing the guard page just after the buffer, it is placed immediately in front of the stack since stacks grow from higher addresses to lower address on Intel X86 processors. The stack overrun detection feature is enabled for all threads in the system by launching the server in the following manner:

    server -o

A stack overrun is manifest by a double fault abend. When this occurs, it is just a matter of walking the stack to find out what code path was taken to overrun the stack.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© 2014 Novell