Debugging a Program With dbx

Chapter 15 Collecting Data

During the execution of an application, the Sampling Collector gathers behavior data and writes it to a file, called an experiment.

When collecting behavior data, you can define the following:

The directory and file name to which you want experiment data written

The period of time during which to sample data

The type of data to collect

For best results, you should compile your application using the -g option, which allows the compiler to provide more detailed information for the Collector to gather.

For more information, see "Collecting Performance Data" in the Sun WorkShop online help and the Analyzing Program Performance With Sun WorkShop manual.

This chapter is organized into the following sections:

Using the Sampling Collector

Before you can collect data, runtime checking must be turned off.

There are a series of collector commands that you can use to collect performance data.

To start collecting data, use one of the following:

collector sample mode continuous
collector sample mode manual

Profiling

For non-multithreaded applications, you can get profiling for a selected region of the code by turning on profiling in the middle of the run and then turning it off at a convenient location. Given the restriction that you cannot turn on profiling in the middle of the run, you can get profiling for a selected region of code with the following:

You can't set this once the program starts running

Don't want profiling for the whole application

This is OK now because it was setup before the program run.

collector sample mode [ manual | continuous ] collector profile mode [ pc_only | stack ] stop in main run collector profile mode off .... #When you reach the beginning of the interesting point: collector profile mode [ pc_only | stack ] .... #When you reach the end of the interesting point: collector profile mode off

Collecting Data for Multithreaded Applications

Data collection for multithreaded applications is supported. There are some restrictions and limitation about multithreaded collection:

You cannot collect information about the code that executes in the init sections of shared libraries (a.out is ok).

For profiling, there are some restrictions:
- It is only supported on Solaris 2.5 or 2.6.
- You cannot start profiling in the middle of the run. You have to start it in the beginning. However, you can disable it in the middle of run and then enable it again.
- You cannot change the profile timer in the middle of the run.

For multithreaded collecting:

collectormt

Command Reference

The syntax of the command is:

collector collector_commands

To stop collecting data, use one of these commands:

collector sample mode off
quit

collector show options

To show settings of one or more categories

options can be:

no option	List setting options
`-profile`	Show profile settings
`-sample`	Show sample settings
`-store`	Show store settings
`-working_set`	Show working_set settings

For example:

collector show

To specify profile options:

collector profile options

options can be:

`-mode stack \| pc_only \| off`	Specifies profile data collection mode
`-timer` `milliseconds`	Stops collecting performance data

For example:

collector profile mode stack

To specify one or more sample options:

collector sample options

options can be:

`-mode continuous \| manual \| off`	Specifies data collection mode
`-timer` `milliseconds`	Specifies data collecting period

For example:

collector sample timer 20

To inquire status about current experiment:

collector status

To find the directory or file name of the stored experiment:

collector store options

options can be:

`-directory` `string`	Specifies directory where experiment is stored
`-filename` `string`	Specifies experiment file name

For example:

collector store directory ".test.z.er"

To specify working_set options:

collector working_set options

options can be:

-mode on | off

Specifies data collection mode

For example:

collector working_set mode off