Collecting Data From a Running Process With dbx on Solaris Platforms

On Solaris platforms, the Collector allows you to collect data from a running process. If the process is already under the control of dbx, you can pause the process and enable data collection using the methods described in previous sections. Starting data collection on a running process is not supported on Linux platforms.

If the process is not under the control of dbx, the collect –P pid command can be used to collect data from a running process, as described in Collecting Data From a Running Process Using the collect Utility. You can also attach dbx to it, collect performance data, and then detach from the process, leaving it to continue. If you want to collect performance data for selected descendant processes, you must attach dbx to each process.

To Collect Data From a Running Process That is Not Under the Control of dbx

1. Determine the program’s process ID (PID).

   If you started the program from the command line and put it in the background, its PID will be printed to standard output by the shell. Otherwise you can determine the program’s PID by typing the following.

   % ps -ef | grep program-name

2. Attach to the process.

   From dbx, type the following.

   (dbx) attach program-name pid

   If dbx is not already running, type the following.

   % dbx program-name pid

   Attaching to a running process pauses the process.

   See the manual Oracle Solaris Studio 12.2: Debugging a Program With dbx for more information about attaching to a process.

3. Start data collection.

   From dbx, use the collector command to set up the data collection parameters and the cont command to resume execution of the process.

4. Detach from the process.

   When you have finished collecting data, pause the program and then detach the process from dbx.

   From dbx, type the following.

   (dbx) detach

Collecting Tracing Data From a Running Program

If you want to collect any kind of tracing data, you must preload the Collector library, libcollector.so , before you run your program. To collect heap tracing data or synchronization wait tracing data, you must also preload er_heap.so and er_sync.so, respectively. These libraries provide wrappers to the real functions that enable data collection to take place. In addition, the Collector adds wrapper functions to other system library calls to guarantee the integrity of performance data. If you do not preload the libraries, these wrapper functions cannot be inserted. See Using System Libraries for more information on how the Collector interposes on system library functions.

To preload libcollector.so, you must set both the name of the library and the path to the library using environment variables, as shown in the table below. Use the environment variable LD_PRELOAD to set the name of the library. Use the environment variables LD_LIBRARY_PATH, LD_LIBRARY_PATH_32, or LD_LIBRARY_PATH_64 to set the path to the library. LD_LIBRARY_PATH is used if the _32 and _64 variants are not defined. If you have already defined these environment variables, add new values to them.

Table 3-2 Environment Variable Settings for Preloading libcollector.so, er_sync.so, and er_heap.so

If your Oracle Solaris Studio software is not installed in /opt/solstudio12.2, ask your system administrator for the correct path. You can set the full path in LD_PRELOAD, but doing this can create complications when using SPARC V9 64-bit architecture.