Specifications

Red Hat Enterprise Linux to Oracle Solaris Porting Guide

and recompile a native source file and continue executing without rebuilding the entire program. You

can resume running from the code fix location. You do not need to relink or reload to continue

debugging. In dbx, you can also navigate between threads, suspend, step a thread, and display the

stack and locks.

Tools for Addressing Specific Issues

• Memory access errors or leaks (discover, mdb libumem): There are number of dbx

commands for detecting memory leaks. For example, the dbx check memusage command

enables memory leak detection and memory usage summary reports at program exit. The

showleaks command shows memory leaks when you've stopped at a breakpoint, and you can use

the dbx showmemuse command to see the memory usage report when you've stopped at a

breakpoint. Through dbxenv variables rtc_error_log_file_name and

rtc_mel_at_exit, you can specify where you want the summary report written to and control

the verbosity of the memory usage report at the end of execution.

• Hot locks (lockstat, plockstat): The lockstat and plockstat tools are built-in Oracle

Solaris 11 tools. plockstat is used to find locks in applications, while lockstat will report

kernel lock and profiling statistics.

• Code coverage (uncover): uncover is a command-line tool for measuring the code coverage of

user applications. This tool can display information about areas of the application being exercised

during testing. The coverage information reported by this tool could be at a function level, statement

level, block level, or instruction level.

• Data races and deadlocks (Thread Analyzer): You can use Thread Analyzer to nail down

difficult-to-detect code issues in multithreaded programs. For example, it helps you detect data races

and deadlock conditions.

Identifying Issues Using DTrace

DTrace is a comprehensive dynamic tracing framework for troubleshooting kernel and application

problems on production systems in real time. DTrace can be used to get a global overview of a running

system, such as the amount of memory, the CPU time, and file system and network resources used by

the active processes. It can also provide much more fine-grained information, such as a log of the

arguments with which a specific function is being called or a list of the processes accessing a specific

file. It is a very powerful dynamic tracing tool that can trace any part of the system. You can

instrument the system by writing a simple Dtrace script. The tracing gets enabled only for the code

area (probe) mentioned in the Dtrace script. Hence, there is near zero overhead on the system when

the probes are not enabled. This infrastructure can be safely used in production (assuming the user

knows the possible overhead and impact of the script.)

Please refer to the following resources for additional information about DTrace tools:

• DTrace toolkit, which is a set of ready-to-use DTrace scripts written by Brendan Gregg and available

for free download at

http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit