NetWare 5 Memory Debugging Features
Novell Cool Solutions: Feature
|
Digg This -
Slashdot This
Posted: 23 Jun 2000 |
OVERVIEW
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 DETECTION, FREED MEMORY ACCESS DETECTION
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.
INTERNAL DEBUGGER MEMORY COMMANDS
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
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. www.webwiseone.com