JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Studio 12.3: Debugging a Program With dbx     Oracle Solaris Studio 12.3 Information Library
search filter icon
search icon

Document Information


1.  Getting Started With dbx

2.  Starting dbx

3.  Customizing dbx

4.  Viewing and Navigating To Code

5.  Controlling Program Execution

6.  Setting Breakpoints and Traces

7.  Using the Call Stack

8.  Evaluating and Displaying Data

9.  Using Runtime Checking

Capabilities of Runtime Checking

When to Use Runtime Checking

Runtime Checking Requirements

Using Runtime Checking

Turning On Memory Use and Memory Leak Checking

Turning On Memory Access Checking

Turning On All Runtime Checking

Turning Off Runtime Checking

Running Your Program

Using Access Checking

Understanding the Memory Access Error Report

Memory Access Errors

Using Memory Leak Checking

Detecting Memory Leak Errors

Possible Leaks

Checking for Leaks

Understanding the Memory Leak Report

Generating a Leak Report

Combining Leaks

Fixing Memory Leaks

Using Memory Use Checking

Suppressing Errors

Types of Suppression

Suppression by Scope and Type

Suppression of Last Error

Limiting the Number of Errors Reported

Suppressing Error Examples

Default Suppressions

Using Suppression to Manage Errors

Using Runtime Checking on a Child Process

Using Runtime Checking on an Attached Process

On a System Running Solaris

On a System Running Linux

Using Fix and Continue With Runtime Checking

Runtime Checking Application Programming Interface

Using Runtime Checking in Batch Mode

bcheck Syntax

bcheck Examples

Enabling Batch Mode Directly From dbx

Troubleshooting Tips

Runtime Checking Limitations

Works Better With More Symbols and Debug Information

SIGSEGV and SIGALTSTACK Signals Are Restricted on x86 Platforms

Works Better When Sufficient Patch Area is Available Within 8 MB of All Existing Code (SPARC platforms only).

Runtime Checking Errors

Access Errors

Bad Free (baf) Error

Duplicate Free (duf) Error

Misaligned Free (maf) Error

Misaligned Read (mar) Error

Misaligned Write (maw) Error

Out of Memory (oom) Error

Read From Array Out-of-Bounds (rob) Error

Read From Unallocated Memory (rua) Error

Read From Uninitialized Memory (rui) Error

Write to Array Out-of-Bounds Memory (wob) Error

Write to Read-Only Memory (wro) Error

Write to Unallocated Memory (wua) Error

Memory Leak Errors

Address in Block (aib) Error

Address in Register (air) Error

Memory Leak (mel) Error

10.  Fixing and Continuing

11.  Debugging Multithreaded Applications

12.  Debugging Child Processes

13.  Debugging OpenMP Programs

14.  Working With Signals

15.  Debugging C++ With dbx

16.  Debugging Fortran Using dbx

17.  Debugging a Java Application With dbx

18.  Debugging at the Machine-Instruction Level

19.  Using dbx With the Korn Shell

20.  Debugging Shared Libraries

A.  Modifying a Program State

B.  Event Management

C.  Macros

D.  Command Reference


Suppressing Errors

Runtime checking provides a powerful error suppression facility that allows great flexibility in limiting the number and types of errors reported. If an error occurs that you have suppressed, then no report is given, and the program continues as if no error had occurred.

You can suppress errors using the suppress command (see suppress Command).

You can undo error suppression using the unsuppress command (see unsuppress Command).

Suppression is persistent across run commands within the same debug session, but not across debug commands.

Types of Suppression

The following types of suppression are available:

Suppression by Scope and Type

You must specify which type of error to suppress. You can specify which parts of the program to suppress. The options are:

The default; applies to the whole program.
Load Object
Applies to an entire load object, such as a shared library, or the main program.
Applies to all functions in a particular file.
Applies to a particular function.
Applies to a particular source line.
Applies to a particular instruction at an address.

Suppression of Last Error

By default, runtime checking suppresses the most recent error to prevent repeated reports of the same error. This is controlled by the dbx environment variable rtc_auto_suppress. When rtc_auto_suppress is set to on (the default), a particular access error at a particular location is reported only the first time it is encountered and suppressed thereafter. This is useful, for example, for preventing multiple copies of the same error report when an error occurs in a loop that is executed many times.

Limiting the Number of Errors Reported

You can use the dbx environment variable rtc_error_limit to limit the number of errors that will be reported. The error limit is used separately for access errors and leak errors. For example, if the error limit is set to 5, then a maximum of five access errors and five memory leaks are shown in both the leak report at the end of the run and for each showleaks command you issue. The default is 1000.

Suppressing Error Examples

In the following examples, is a file name, foo and bar are functions, and a.out is the name of an executable.

Do not report memory leaks whose allocation occurs in function foo.

suppress mel in foo

Suppress reporting blocks in use allocated from

suppress biu in

Suppress read from uninitialized in all functions in a.out.

suppress rui in a.out

Do not report read from unallocated in file

suppress rua in

Suppress duplicate free at line 10 of

suppress duf at

Suppress reporting of all errors in function bar.

suppress all in bar

For more information, see suppress Command.

Default Suppressions

To detect all errors, runtime checking does not require the program be compiled using the- g option (symbolic). However, symbolic information is sometimes needed to guarantee the correctness of certain errors, mostly rui errors. For this reason certain errors, rui for a.out and rui, aib, and air for shared libraries, are suppressed by default if no symbolic information is available. This behavior can be changed using the -d option of the suppress command and unsuppress command.

The following command causes runtime checking to no longer suppress read from uninitialized memory (rui) in code that does not have symbolic information (compiled without -g):

unsuppress -d rui

For more information, see unsuppress Command.

Using Suppression to Manage Errors

For the initial run on a large program, the large number of errors might be overwhelming. It might be better to take a phased approach. You can do so using the suppress command to reduce the reported errors to a manageable number, fixing just those errors, and repeating the cycle; suppressing fewer and fewer errors with each iteration.

For example, you could focus on a few error types at one time. The most common error types typically encountered are rui, rua, and wua, usually in that order. rui errors are less serious (although they can cause more serious errors to happen later). Often a program might still work correctly with these errors. rua and wua errors are more serious because they are accesses to or from invalid memory addresses and always indicate a coding error.

You can start by suppressing rui and rua errors. After fixing all the wua errors that occur, run the program again, this time suppressing only rui errors. After fixing all the rua errors that occur, run the program again, this time with no errors suppressed. Fix all the rui errors. Lastly, run the program a final time to ensure no errors are left.

If you want to suppress the last reported error, use suppress -last.