Overview
HP WDB collects and reports heap usage information and detects memory usage problems such as memory leaks and bad calls to free().
For memory usage problems such as freeing an unallocated memory block, HP WDB can stop your program as soon as the problem is detected. For other types of memory problems, such as memory leaks, WDB collects data and reports the results in the Memory Usage View.
Memory Problems and Conditions Detected
HP WDB memory checking features let you check for the following types of memory problems and conditions:
- Freeing of an unallocated or deallocated block addresses.
- Writing beyond the bounds of an allocated memory block, detected when the block is freed.
- Identifying memory allocations exceeding a given number of bytes.
- Specific memory allocations that cause heap growth exceeding a given number of bytes.
- Memory leaks.
Additionally, HP WDB can report on the current state of your program's heap usage, and can scramble memory when blocks of memory are allocated or deallocated. This feature helps you detect when your program reads uninitialized blocks of allocated memory.
Preparing Your Program for Memory Checking
To use HP WDB's memory checking facilities, you must link your application with librtc.sl. Link with the version of librtc.sl appropriate for your executable:
-L/opt/langtools/lib -lrtc
(32-bit applications)
-L/opt/langtools/lib/pa20_64 -lrtc
(64-bit applications)
NOTE: 32-bit applications running on HP-UX 11.0 (or later) with version B.11.17 of ld and dld (or later) do not need to link librtc.sl. |
Enabling Memory Checking and Data Collection
If you link your program with librtc.sl, you can start memory checking and data collection by choosing Memory Check... from the Tools menu. The dialog box lets you choose the types of memory checking and data collection you want to enable.
| NOTE: You must enable memory checking and data collection before running your program in the debugger. Additionally, if you change memory checking and data collection settings during a program run, you may need to rerun your program for the new settings to take effect. |
The memory checking features you can enable in the Memory Check dialog are:
- Stop at free of an unallocated or deallocated block address.
Monitors bad calls to free() in your code. Bad calls to free() include freeing addresses that have either never been allocated or have already been freed. When the debugger detects a bad call to free(), it stops your program and reports the bad call in the status bar at the bottom of the debugger window.
If the debugger detects a bad call to free() that results from freeing the same memory block more than once, you can track down the first free of the block of memory by checking the box next to Stop if the following block address is allocated or deallocated. Refer to the description for details.
- Stop when block is freed if bad writes occurred before or after block bounds.
Detects a write to a block of memory beyond the bounds allocated for that block. The debugger checks for bad writes only when blocks are freed, not when the bad writes actually occur. When the debugger detects a bad write, it stops your program and reports details of the bad write in the status bar at the bottom of the debugger window.
- Scramble previous memory contents on malloc/free.
Helps you to find where you program reads uninitialized memory. This feature scrambles or uninitializes a memory location with preset patterns on malloc() and free() calls.
The data your program gets when reading uninitialized memory can appear random, causing intermittent and hard to predict problems in your program's behavior. By scrambling memory at malloc() and free() calls, the debugger can make it more likely that your program will consistently manifest problems resulting from uninitialized reads, making it easier to track down such problems.
- Stop if the following block address is allocated or deallocated.
Monitors allocations and deallocations of a particular block address in your code. If the block address you specify is allocated or deallocated, the debugger stopd your program and report the allocation/deallocation.
Use this feature if you discover that a block of memory is being freed twice. To find the first free of the block, select this option and specify the address of the block being freed twice. When you rerun your program, the debugger stops at the first free of the address.
- Stop when an allocation causes heap growth exceeding num (bytes).
Monitors the amount of heap growth caused by memory allocations. If the heap grows beyond the limit you specify due to a single memory allocation request, the debugger stops your program and reports this in the status bar at the bottom of the debugger window.
- Stop when an allocation exceeds num (bytes).
Monitors memory allocations. If the number of bytes allocated by a single allocation request exceeds the number of bytes you specify, the debugger stops your program and reports this in the status bar at the bottom of the debugger window.
- Collect memory leak/usage data (reported in Memory Usage View).
Causes the debugger to collect data on your program's memory use. When the data is collected, you can view it in the Memory Usage View See Using the Memory Usage View for details.
| NOTE: The debugger discards the memory data it has collected when your application exits. Set a breakpoint at program exit if you want to update the memory reports before your application exits. |
You can control the amount of memory use data collected by specifying either or both of the following:
- Report stack trace if block size is greater than number of bytes
Set the number of bytes field to one less than the minimum size memory leak or memory allocation you want reported. Larger values improve run-time performance of your program. Block sizes less than the value your specify are still reported, but no stack trace is available.
- Maximum stack depth to report.
Set the number in this field to control how many stack frames are recorded at each memory allocation. Smaller values improve run-time performance of your program.
Using the Memory Usage View
The Memory Usage view reports data that the debugger collects on your program's memory leaks and heap use. You must enable leak and memory use data collection prior to running your program. See Enabling Memory Checking and Data Collection for details.
When you run your program in the debugger with memory leak and memory use data collection enabled, you can stop your program at any time to get:
- A cumulative report on memory leaks.
- A report on the current state of the heap.
You can set any number of breakpoints and examine how leaks and memory use are affected by your program's behavior between breakpoints.
Viewing Memory Leak and Memory Use Reports
To view a memory leak or memory (heap) use report:
- In the debugger main window, click the Memory Usage tab.
- Click the checkbox for the type of report you want: Memory Leaks or Memory Use.
- Right-click on the Memory Usage pop up menu and choose Update to ensure the report contains the latest leak or memory use information.
The report contains a list of entries describing specific memory leaks or memory allocations.
Examining Entries in Memory Leak and Memory Use Reports
Each entry in the memory leak or memory use report describes one or more memory leaks or memory allocations. Memory leaks or memory allocations that share the same stack trace are grouped together. Each entry contains the following information:
| Num |
ID assigned to individual memory leak or memory use report entries. |
| Total Bytes |
Total bytes leaked (leak report) or allocated (memory use report) for one report entry. |
| #Blocks |
Number of blocks of memory allocated for the given entry. Individual blocks can vary in size. The sum of their sizes is reported as Total Bytes. |
| Address |
Address of the block of memory used or leaked. If there are multiple blocks, then this is the address of an arbitrary block from the group of blocks. |
| Function |
Shows the function that allocated memory. When you expand an entry in the report, this field shows the stack trace at the time of the memory allocation. |
| File |
File containing the reported function. |
Viewing the Stack and Source Associated with Leaks and Allocations
In the memory leak or memory use report there is a small box to the left of each
entry. Click on the box to reveal the stack trace associated with an entry. To view
the source for a routine on the stack, simply double-click on the routine name.
The source view display the file and appropriate line of code.
To save the memory leak or memory (heap) use report to a file:
- In the debugger main window, click the Memory Usage tab.
- Click the checkbox to select the type of report you want: Memory Leaks or Memory Use.
- Right-click on the report and in the pop up menu click Save To File.
- Clicking on Save To File will bring up the File Selection Dialog.
- In the Directories list, double-click to select the appropriate directory.
- Select an existing file from the Files list or specify a new file.
- Clicking on OK will save the memory report to the specified file.
- Clicking on Cancel will exit the File Selection Dialog without saving the memory report.
|
Note: The log file will contain only the current log.
Previous logs will not be preserved.
|
HP WDB does not support memory checking for the following types of programs:
- Programs that use CMA or DCE threads.
- Programs that use Open Graphics
- Programs that link with
-N to generate an EXEC_MAGIC executable.
- 64-bit programs that use a version of
malloc() other than standard C library (libc.sl) version of malloc().
- Programs that link the archive version of the standard C library (
libc.a) or the core library (libcl.a) or both.
Tips
Enabling memory checking and data collection causes some performance and memory overhead for the debugger. When you enable collecting memory use and leak data, you can reduce performance and memory overhead by:
- Setting the minimum block size to a high value. This causes the debugger to collect stack traces only for block sizes greater than the value you specify. Block sizes less than the value your specify are still reported, but no stack trace is available.
- Setting the maximum stack depth reported to a low value. This decreases the number of stack frame routine names saved for each leak or allocation.
Note that when you increase the minimum block size and decrease the maximum stack
depth, you loose contextual information for individual leak and allocation reports.
Return to Top
|
