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

Preface

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

Index

Using Runtime Checking in Batch Mode

The bcheck utility is a convenient batch interface to the runtime checking feature of dbx. It runs a program under dbx and by default, places the runtime checking error output in the default file program.errs.

The bcheck utility can perform memory leak checking, memory access checking, memory use checking, or all three. Its default action is to perform only leak checking. See the bcheck(1) man page for more details on its use.


Note - Before running the bcheck utility on a system running the 64-bit Linux OS, you must set the _DBX_EXEC_32 environment variable.


bcheck Syntax

The syntax for bcheck is:

bcheck [-V] [-access | -all | -leaks | -memuse] [-xexec32] [-o logfile] [-q]
[-s script] program [args]

Use the -o logfile option to specify a different name for the logfile. Use the -s script option before executing the program to read in the dbx commands contained in the file script. The script file typically contains commands like suppress and dbxenv to tailor the error output of the bcheck utility.

The -q option makes the bcheck utility completely quiet, returning with the same status as the program. This option is useful when you want to use the bcheck utility in scripts or makefiles.

bcheck Examples

To perform only leak checking on hello, type:

bcheck hello

To perform only access checking on mach with the argument 5, type:

bcheck -access mach 5

To perform memory use checking on cc quietly and exit with normal exit status, type:

bcheck -memuse -q cc -c prog.c

The program does not stop when runtime errors are detected in batch mode. All error output is redirected to your error log file logfile. The program stops when breakpoints are encountered or if the program is interrupted.

In batch mode, the complete stack backtrace is generated and redirected to the error log file. The number of stack frames can be controlled using the dbx environment variable stack_max_size.

If the file logfile already exists, bcheck erases the contents of that file before it redirects the batch output to it.

Enabling Batch Mode Directly From dbx

You can also enable a batch-like mode directly from dbx by setting the dbx environment variables rtc_auto_continue and rtc_error_log_file_name (see Setting dbx Environment Variables).

If rtc_auto_continue is set to on, runtime checking continues to find errors and keeps running automatically. It redirects errors to the file named by the dbx environment variable rtc_error_log_file_name. (See Setting dbx Environment Variables.) The default log file name is /tmp/dbx.errlog.uniqueid. To redirect all errors to the terminal, set the rtc_error_log_file_name environment variable to /dev/tty.

By default, rtc_auto_continue is set to off.