Native Inspect Manual (H06.13+, J06.03+)

increase and this can result in serious consequences for long-running applications and memory
intensive applications.
Memory leaks can also cause fragmentation of the heap. This slows down the allocation,
de-allocation, and access of memory blocks and can eventually cause the application to fail with
out-of-memory errors.
You should suspect a memory leak in an application if the system runs out of swap space, runs
slower, or both. Memory leaks in an application increase the memory consumption in an application.
When the memory consumed by the application exceeds the resource limits set by the kernel, the
application fails with out-of-memory errors.
NOTE: For programs compiled at all optimization levels, a memory leak may be reported at a
line in the code that does not match the actual leak location. This only happens when the memory
allocation and the leak happen in the same block of statements containing no control flow (which
is not common).
Access Errors
Memory access errors can occur under the following conditions:
• When reading uninitialized local, or heap data
• When reading or writing to nonexistent or unallocated memory
• When a stray pointer overflows the bounds of a heap block, or tries to access a heap block
that is already freed to cause buffer overruns and underruns
• When reading or writing to memory locations that are already freed in the program
Commands For Interactive Memory Debugging
You can use the memory leak detection commands, described in Chapter 4: Native Inspect
Command Syntax, to debug memory problems through Native Inspect.
For more information on memory debugging with Native Inspect, see the Debugging Dynamic
Memory Usage Errors Using HP WDB white paper and the Debugging with GDB manual at the
HP WDB Documentation webpage: http://www.hp.com/go/WDB. Native Inspect's implementation
of memory debugging is similar to that of WDB.
Handling Events
When Native Inspect receives an event, it informs you what event has occurred and then updates
the debugging context (that is, information specific to the current process, such as breakpoints,
loaded DLLs, and the current register values).
The type of events that have the most impact on debugging with Native Inspect are debugging
events, which typically suspend a program under debugger control. For example, a breakpoint is
a debugger-induced debugging event.
Specific responses to significant events are listed in Table 6.
Assessing Your Location After an Event
If you are uncertain about your current program location after an event occurs, you can list the
current frame by using the frame command, or the select-frame command as follows:
(eInspect 6,679):frame
#0 test_complexTypes() () at \SYS03.$D007.SYMBAT1.SCXXTST:424
424 printf( "%s test_complexTypes\n", getStepPrefix( 1 ) );
30 Introducing Native Inspect