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

Starting a Debugging Session

Debugging a Core File

Debugging a Core File in the Same Operating Environment

If Your Core File Is Truncated

Debugging a Mismatched Core File

Eliminating Shared Library Problems

Things to Remember

Using the Process ID

The dbx Startup Sequence

Setting Startup Properties

Mapping the Compile-time Directory to the Debug-time Directory

Setting dbx Environment Variables

Creating Your Own dbx Commands

Compiling a Program for Debugging

Compiling with the -g Option

Using a Separate Debug File

Creating a Separate Debug File

Debugging Optimized Code

Parameters and Variables

Inlined Functions

Code Compiled Without the -g Option

Shared Libraries Require the -g Option for Full dbx Support

Completely Stripped Programs

Quitting Debugging

Stopping a Process Execution

Detaching a Process From dbx

Killing a Program Without Terminating the Session

Saving and Restoring a Debugging Run

Using the save Command

Saving a Series of Debugging Runs as Checkpoints

Restoring a Saved Run

Saving and Restoring Using replay

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

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

Debugging a Core File

If the program that dumped core was dynamically linked with any shared libraries, it is best to debug the core file in the same operating environment in which it was created. dbx has limited support for the debugging of “mismatched” core files (for example, core files produced on a system running a different version or patch level of the Solaris Operating System.


Note - dbx cannot tell you the state of a Java application from a core file as it can with native code.


Debugging a Core File in the Same Operating Environment

To debug a core file, type:

$ dbx program_name core

or

$ dbxtool program_name core

If you type the following, dbx determines the program_name from the core file:

$ dbx - core

or

$ dbxtool - core

You can also debug a core file using the debug command when dbx is already running:

(dbx) debug -c core program_name

You can substitute - for the program name and dbx will attempt to extract the program name from the core file. dbx might not find the executable if its full path name is not available in the core file. If dbx does not find the executable, specify the complete path name of the binary when you tell dbx to load the core file.

If the core file is not in the current directory, you can specify its path name (for example, /tmp/core).

Use the where command (see where Command) to determine where the program was executing when it dumped core.

When you debug a core file, you can also evaluate variables and expressions to see the values they had at the time the program crashed, but you cannot evaluate expressions that make function calls. You cannot single step. You can set breakpoints and then rerun the program.

If Your Core File Is Truncated

If you have problems loading a core file, check whether you have a truncated core file. If you have the maximum allowable size of core files set too low when the core file is created, then dbx cannot read the resulting truncated core file. In the C shell, you can set the maximum allowable core file size using the limit command (see the limit(1) man page). In the Bourne shell and Korn shell, use the ulimit command (see the limit(1) man page). You can change the limit on core file size in your shell start-up file, re-source the start-up file, and then rerun the program that produced the core file to produce a complete core file.

If the core file is incomplete, and the stack segment is missing, then stack trace information is not available. If the runtime linker information is missing, then the list of loadobjects is not available. In this case, you get an error message about librtld_db.so not being initialized. If the list of LWPs is missing, then no thread information, lwp information, or stack trace information is available.If you run the where command, you get an error saying the program was not “active.”

Debugging a Mismatched Core File

Sometimes a core file is created on one system (the core-host) and you want to load the core file on another machine (the dbx-host) to debug it. However, two problems with libraries might arise when you do so:

The user libraries and system libraries can change in patches as well as major Solaris operating environment upgrades, so this problem can even occur on the same host, if, for example, a patch was installed after the core file was collected, but before running dbx on the core file.

dbx might display one or more of the following error messages when you load a “mismatched” core file:

dbx: core file read error: address 0xff3dd1bc not available
dbx: warning: could not initialize librtld_db.so.1 -- trying libDP_rtld_db.so
dbx: cannot get thread info for 1 -- generic libthread_db.so error
dbx: attempt to fetch registers failed - stack corrupted
dbx: read of registers from (0xff363430) failed -- debugger service failed

Eliminating Shared Library Problems

To Eliminate the Library Problems and Debug a “mismatched” Core File

  1. Set the dbx environment variable core_lo_pathmap to on.
  2. Use the pathmap command to tell dbx where the correct libraries for the core file are located.
  3. Use the debug command to load the program and the core file.

    For example, assuming that the root partition of the core-host has been exported over NFS and can be accessed using /net/core-host/ on the dbx-host machine, you would use the following commands to load the program prog and the core file prog.core for debugging:

    (dbx) dbxenv core_lo_pathmap on
    (dbx) pathmap /usr /net/core-host/usr
    (dbx) pathmap /appstuff /net/core-host/appstuff
    (dbx) debug prog prog.core

    If you are not exporting the root partition of the core-host, you must copy the libraries by hand. You need not re-create the symbolic links. (For example, you need not make a link from libc.so to libc.so.1; just make sure libc.so.1 is available.)

Things to Remember

Keep the following things in mind when debugging a mismatched core file: