Debugging Dynamic Memory Usage Errors Using NonStop Native Inspect HP Part Number: 658198-002 Published: August 2011 Edition: 1.
Legal Notices © Copyright 2011 Hewlett-Packard Company, L.P. Confidential Computer Software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.11 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. The information contained herein is subject to change without notice.
Contents Introduction..............................................................................................................................4 Intended Audience....................................................................................................................4 Typographic Conventions...........................................................................................................4 Related Information.............................................................................
Introduction HP NonStop Debugger (Native Inspect) is an HP-supported implementation of the open source debugger GDB. In addition to the normal debugging functions, it also enables you to debug memory-related errors in a program. Native Inspect supports memory-debugging (using Run Time Checking (RTC)) of source-level programs written in HP NonStop C and HP NonStop C++ on Itanium®-based systems running the NonStop Guardian or OSS operating systems.
heap_check() will perform a sanity check over the memory management internal data structures. The function heap_check_always()turns on heap checking in the runtime library enabling checking for every memory-related call into the runtime library (for example a call to malloc()). This method of doing memory checking is more limited than what is described here. It will not compute any memory leak information nor are there any checks for improper use of calls to string functions.
• Memory leak reports etc. can not be generated from a process which has been suspended at stop or abend. • The memory debugging feature can not be used with applications that redefine or override the default system-supplied versions of the standard library routines (under zcredll, and zcrtldll), such as abort(), strcat(), and dlclose(). If there are doubts about the applications’ use of memory functions, one can use the enoft utility.
leaks memory on a continual basis, the virtual memory requirement for the process continues to 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, deallocation, and access of memory blocks and can eventually cause the application to fail with out-of-memory errors.
NOTE: Native Inspect supports the debugging of physical memory leaks only. It does not detect logical memory leaks. Access Errors Memory access errors can occur under the following conditions: • When reading uninitialized local or heap data. • When reading or writing to nonexistent, unallocated, or unmapped 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 under-runs.
Heap Profiling You can profile the heap usage in an application by using Native Inspect. The heap-profiling feature enables you to analyze the influence of algorithms and data structures on heap usage and tune the memory requirements of an application. The point-in-time (meaning the application is suspended at some point in execution) profile displays the outstanding heap allocations at a specific instant (probe point) at runtime. It does not display the blocks that are already freed before the probe point.
50769 bytes allocated in 1011 blocks No. Total bytes Blocks Address Function 0 49000 1000 0x08434cb0 main() [...] 5. To view a specific allocation, specify the allocation number as an argument to the info heap command. For example: (eInspect 0,105): info heap 1 4096 bytes at 0x7bd63000 (9.86% of all bytes allocated) in h_func () at testc:108 in main () at testc:17 in _start () in $START$ () You can control the stack frames that are collected for reporting at any allocation point.
NOTE: The “” function displayed indicates memory allocated from an unknown function (function with no name) or system routine. Leak Profiling The leak profile feature in Native Inspect conservatively identifies the blocks of memory that are leaked in an application, and displays the stack trace that shows when the block was allocated. All the leaks detected by Native Inspect are definite physical leaks.
NOTE: Alternatively, you can use the set heap-check on command to automatically enable the detection of leaks by toggling the set heap-check leaks on command. This command enables the detection of leaks, heap profiles, bounds checking, and checking for double frees. 3. Set breakpoints in the code at probe-points where you want to examine cumulative leaks by entering the following command: (eInspect 0,105): b 4.
set heap-check block-size Example 2 Monitoring allocations greater than a specified size Sample Program 1 #include 2 3 int main() 4 { 5 char * cp; 6 printf("Start of the program\n"); 7 cp = (char *)malloc(1024 *1024*10); 8 free (cp); 9 exit(0); 10 } Sample Debugging Session (eInspect 1,575): set heap-check on (eInspect 1,575): set heap-check block-size 900000 (eInspect 1,575): b 9 Breakpoint 2 at 0x70000b00:1: file \PELICAN.$DATA4.USER.EX2C, line 9. (eInspect 1,575): c Continuing.
Table 5 Commands for Monitoring Heap Corruption Command Description set heap-check string Toggles validation of calls to strcpy(), strncpy(), memcpy(), memccpy(),memset(), memmove(), bzero(), strdup(),and, bcopy(). set heap-check bounds Toggles the bounds-checking feature for detection of heap-corruption in Native Inspect. info corruption Displays a list of all the dangling pointers and dangling blocks that are potential sources of memory corruption.
__rtc_event (ecode=RTC_BAD_STRCPY, pointer=0x8429d18, pclist=0x8404a4c, size=20) at c:\t1237\h0616\wdb\build\ia64-hp-nsk-native\ gdb\../../../Src/gnu/gdb\infrtc.c:1901 c:\t1237\h0616\wdb\build\ia64-hp-nsk-native\ gdb\../../../Src/gnu/gdb\infrtc.c:1901: Guardian or User Defined Error 13 (eInspect 1,1193): bt #0 __rtc_event (ecode=RTC_BAD_STRCPY, pointer=0x8429d18, pclist=0x8404a4c, size=20) at c:\t1237\h0616\wdb\build\ia64-hp-nsk-native\ gdb\../../../Src/gnu/gdb\infrtc.
7 8 9 10 11 strcpy(cp,"Hello"); cp[100] = 100; free(cp); exit(0); } Sample Debugging Session (eInspect 1,558): set heap-check bounds on (eInspect 1,558): b 10 Breakpoint 2 at 0x70000c10:1: file \PELICAN.$DATA4.USER.EX4C, line 10. (eInspect 1,558): c Continuing. warning: Memory block (size = 100 address = 0x08429cf8) appears to be corrupted at the beginning. Allocation context might not be correct. #1 main() at \PELICAN.$DATA4.USER.EX4C:5 #2 _MAIN() at \SPEEDY.$RLSE.T8432H02.
15 main() 16 { 17 t = (char *)sm_malloc(10); 18 strcpy(t, "123456789123"); 19 t1 = (char *)sm_malloc(10); 20 strcpy(t1, "12345678912"); 21 t2 = (char *)sm_malloc(10); 22 strcpy(t2, "1234567891"); 23 t3 = (char *)sm_malloc(10); 24 strcpy(t3, "123456789"); 25 printf("Hello\n"); 26 free (t); 27 free (t1); 28 free (t2); 29 free (t3); 30 free (t); 31 free (t1); 32 exit(1); 33 } Sample Debugging Session (eInspect 1,666): b 25 Breakpoint 2 at 0x70000e00:1: file \PELICAN.$DATA4.USER.EX5C, line 25.
Supported Modes of Memory-debugging in Native Inspect Native Inspect supports the following modes of memory-debugging: • Interactive mode (debugging programs launched under debugger control) • Attach mode Debugging Programs Launched Under Debugger Control The interactive mode of memory-debugging is typically useful during the development and defect fixing phase, where you need the flexibility to control the flow of program execution while debugging memory related problems.
Summary of Memory Debugging Commands Table 7 Commonly Used Commands for Memory Debugging Description Command Enables heap profiling set heap-check Enables you to detect leaks set heap-check leaks Enables you to detect double-frees and frees with improper set heap-check free arguments Enables you to check for out-of-bounds corruption when the block is freed set heap-check bounds Enables validation of calls to strcpy(), strncpy(), set heap-check string memc
(eInspect 1,1180): n * 9 printf("Now freeing a pointer twice...\n"); (eInspect 1,1180): n * 10 free(han); (eInspect 1,1180): n warning: Attempt to free unallocated or already freed object at 0x0842ad10 __rtc_event (ecode=RTC_BAD_FREE, pointer=0x842ad10, pclist=0x0, size=0) at c:\t1237\h0616\wdb\build\ia64-hp-nsk-native\ gdb\../../../Src/gnu/gdb\infrtc.c:1901 c:\t1237\h0616\wdb\build\ia64-hp-nsk-native\ gdb\../../../Src/gnu/gdb\infrtc.
(eInspect 1,677): n warning: Attempt to free unallocated or already freed object at 0x0842ad2c __rtc_event (ecode=RTC_BAD_FREE, pointer=0x842ad2c, pclist=0x0, size=0) at c:\t1237\h0616\wdb\build\ia64-hp-nsk-native\ gdb\../../../Src/gnu/gdb\infrtc.c:1901 c:\t1237\h0616\wdb\build\ia64-hp-nsk-native\ gdb\../../../Src/gnu/gdb\infrtc.
9 { 10 func1(*ptr); 11 } 12 int main() 13 14 { 15 int* han1; 16 printf("Starting program\n"); 17 func2(&han1); 18 printf("End of the program\n"); 19 } Sample Debugging Session (eInspect 1,707): set heap-check on (eInspect 1,707): b 18 Breakpoint 2 at 0x70000ce0:0: file \PELICAN.$DATA4.USER.EX10C, line 18. (eInspect 1,707): c Continuing. Breakpoint 2, main () at \PELICAN.$DATA4.USER.
(eInspect 1,712): b 17 Breakpoint 2 at 0x70000b60:1: file \PELICAN.$DATA4.USER.EX11C, line 17. (eInspect 1,712): c Continuing. Breakpoint 2, main () at \PELICAN.$DATA4.USER.EX11C:17 * 17 } (eInspect 1,712): info leak Scanning for memory leaks... 50 bytes leaked in 1 blocks No. Total bytes Blocks Address Function 0 50 1 0x08429d18 main() (eInspect 1,712): info leak 0 50 bytes leaked at 0x08429d18 (100.00% of all bytes leaked) #0 main() at \PELICAN.$DATA4.USER.EX11C:13 #1 _MAIN() at \SPEEDY.$RLSE.T8432H02.
8. Does the debugger find leaks in the executable from the startup of the application when debugging the application in attach mode? Yes, the debugger finds leaks in the executable from the startup of the executable by default, when debugging in attach mode. 9. When attempting to view the leak report, the following error occurs: (eInspect 0,105): info leaks Scanning for memory leaks...
