System Interfaces Chapter 2 (original) (raw)

The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition


2.11 Tracing

[TRC] [Option Start]This section describes extensions to support tracing of user applications. This functionality is dependent on support of the Trace option (and the rest of this section is not further marked for this option). [Option End]

The tracing facilities defined in IEEE Std 1003.1-2001 allow a process to select a set of trace event types, to activate a trace stream of the selected trace events as they occur in the flow of execution, and to retrieve the recorded trace events.

The tracing operation relies on three logically different components: the traced process, the controller process, and the analyzer process. During the execution of the traced process, when a trace point is reached, a trace event is recorded into the trace streams created for that process in which the associated trace event type identifier is not being filtered out. The controller process controls the operation of recording the trace events into the trace stream. It shall be able to:

These operations can be done for an active trace stream. The analyzer process retrieves the traced events either at runtime, when the trace stream has not yet been shut down, but is still recording trace events; or after opening a trace log that had been previously recorded and shut down. These three logically different operations can be performed by the same process, or can be distributed into different processes.

A trace stream identifier can be created by a call to posix_trace_create(), posix_trace_create_withlog(), or posix_trace_open(). The posix_trace_create() and posix_trace_create_withlog() functions should be used by a controller process. The posix_trace_open() should be used by an analyzer process.

The tracing functions can serve different purposes. One purpose is debugging the possibly pre-instrumented code, while another is post-mortem fault analysis. These two potential uses differ in that the first requires pre-filtering capabilities to avoid overwhelming the trace stream and permits focusing on expected information; while the second needs comprehensive trace capabilities in order to be able to record all types of information.

The events to be traced belong to two classes:

  1. User trace events (generated by the application instrumentation)
  2. System trace events (generated by the operating system)

The trace interface defines several system trace event types associated with control of and operation of the trace stream. This small set of system trace events includes the minimum required to interpret correctly the trace event information present in the stream. Other desirable system trace events for some particular application profile may be implemented and are encouraged; for example, process and thread scheduling, signal occurrence, and so on.

Each traced process shall have a mapping of the trace event names to trace event type identifiers that have been defined for that process. Each active trace stream shall have a mapping that incorporates all the trace event type identifiers predefined by the trace system plus all the mappings of trace event names to trace event type identifiers of the processes that are being traced into that trace stream. These mappings are defined from the instrumented application by calling the posix_trace_eventid_open() function and from the controller process by calling the posix_trace_trid_eventid_open() function. For a pre-recorded trace stream, the list of trace event types is obtained from the pre-recorded trace log.

The st_ctime and st_mtime fields of a file associated with an active trace stream shall be marked for update every time any of the tracing operations modifies that file.

The st_atime field of a file associated with a trace stream shall be marked for update every time any of the tracing operations causes data to be read from that file.

Results are undefined if the application performs any operation on a file descriptor associated with an active or pre-recorded trace stream until posix_trace_shutdown() or posix_trace_close() is called for that trace stream.

The main purpose of this option is to define a complete set of functions and concepts that allow a conforming application to be traced from creation to termination, whatever its realtime constraints and properties.

2.11.1 Tracing Data Definitions

Structures

The <trace.h> header shall define the posix_trace_status_info and_posix_trace_event_info_ structures described below. Implementations may add extensions to these structures.

posix_trace_status_info Structure

To facilitate control of a trace stream, information about the current state of an active trace stream can be obtained dynamically. This structure is returned by a call to the posix_trace_get_status() function.

The posix_trace_status_info structure defined in <trace.h> shall contain at least the following members:

Member Type Member Name Description
int posix_stream_status The operating mode of the trace stream.
int posix_stream_full_status The full status of the trace stream.
int posix_stream_overrun_status Indicates whether trace events were lost in the trace stream.

If the Trace Log option is supported in addition to the Trace option, the posix_trace_status_info structure defined in <trace.h> shall contain at least the following additional members:

Member Type Member Name Description
int posix_stream_flush_status Indicates whether a flush is in progress.
int posix_stream_flush_error Indicates whether any error occurred during the last flush operation.
int posix_log_overrun_status Indicates whether trace events were lost in the trace log.
int posix_log_full_status The full status of the trace log.

The posix_stream_status member indicates the operating mode of the trace stream and shall have one of the following values defined by manifest constants in the <trace.h> header:

POSIX_TRACE_RUNNING

Tracing is in progress; that is, the trace stream is accepting trace events.

POSIX_TRACE_SUSPENDED

The trace stream is not accepting trace events. The tracing operation has not yet started or has stopped, either following a posix_trace_stop() function call or because the trace resources are exhausted.

The posix_stream_full_status member indicates the full status of the trace stream, and it shall have one of the following values defined by manifest constants in the <trace.h> header:

POSIX_TRACE_FULL

The space in the trace stream for trace events is exhausted.

POSIX_TRACE_NOT_FULL

There is still space available in the trace stream.

The combination of the posix_stream_status and posix_stream_full_status members also indicates the actual status of the stream. The status shall be interpreted as follows:

POSIX_TRACE_RUNNING and POSIX_TRACE_NOT_FULL

This status combination indicates that tracing is in progress, and there is space available for recording more trace events.

POSIX_TRACE_RUNNING and POSIX_TRACE_FULL

This status combination indicates that tracing is in progress and that the trace stream is full of trace events. This status combination cannot occur unless the stream-full-policy is set to POSIX_TRACE_LOOP. The trace stream contains trace events recorded during a moving time window of prior trace events, and some older trace events may have been overwritten and thus lost.

POSIX_TRACE_SUSPENDED and POSIX_TRACE_NOT_FULL

This status combination indicates that tracing has not yet been started, has been stopped by the posix_trace_stop() function, or has been cleared by the posix_trace_clear() function.

POSIX_TRACE_SUSPENDED and POSIX_TRACE_FULL

This status combination indicates that tracing has been stopped by the implementation because the _stream-full-policy_attribute was POSIX_TRACE_UNTIL_FULL and trace resources were exhausted, or that the trace stream was stopped by the function posix_trace_stop() at a time when trace resources were exhausted.

The posix_stream_overrun_status member indicates whether trace events were lost in the trace stream, and shall have one of the following values defined by manifest constants in the <trace.h>header:

POSIX_TRACE_OVERRUN

At least one trace event was lost and thus was not recorded in the trace stream.

POSIX_TRACE_NO_OVERRUN

No trace events were lost.

When the corresponding trace stream is created, the posix_stream_overrun_status member shall be set to POSIX_TRACE_NO_OVERRUN.

Whenever an overrun occurs, the posix_stream_overrun_status member shall be set to POSIX_TRACE_OVERRUN.

An overrun occurs when:

The posix_stream_overrun_status member is reset to zero after its value is read.

If the Trace Log option is supported in addition to the Trace option, the posix_stream_flush_status,posix_stream_flush_error, posix_log_overrun_status, and posix_log_full_status members are defined as follows; otherwise, they are undefined.

The posix_stream_flush_status member indicates whether a flush operation is being performed and shall have one of the following values defined by manifest constants in the header <trace.h>:

POSIX_TRACE_FLUSHING

The trace stream is currently being flushed to the trace log.

POSIX_TRACE_NOT_FLUSHING

No flush operation is in progress.

The posix_stream_flush_status member shall be set to POSIX_TRACE_FLUSHING if a flush operation is in progress either due to a call to the posix_trace_flush() function (explicit or caused by a trace stream shutdown operation) or because the trace stream has become full with the stream-full-policy attribute set to POSIX_TRACE_FLUSH. The posix_stream_flush_status member shall be set to POSIX_TRACE_NOT_FLUSHING if no flush operation is in progress.

The posix_stream_flush_error member shall be set to zero if no error occurred during flushing. If an error occurred during a previous flushing operation, the posix_stream_flush_error member shall be set to the value of the first error that occurred. If more than one error occurs while flushing, error values after the first shall be discarded. The_posix_stream_flush_error_ member is reset to zero after its value is read.

The posix_log_overrun_status member indicates whether trace events were lost in the trace log, and shall have one of the following values defined by manifest constants in the <trace.h> header:

POSIX_TRACE_OVERRUN

At least one trace event was lost.

POSIX_TRACE_NO_OVERRUN

No trace events were lost.

When the corresponding trace stream is created, the posix_log_overrun_status member shall be set to POSIX_TRACE_NO_OVERRUN. Whenever an overrun occurs, this status shall be set to POSIX_TRACE_OVERRUN. The_posix_log_overrun_status_ member is reset to zero after its value is read.

The posix_log_full_status member indicates the full status of the trace log, and it shall have one of the following values defined by manifest constants in the <trace.h> header:

POSIX_TRACE_FULL

The space in the trace log is exhausted.

POSIX_TRACE_NOT_FULL

There is still space available in the trace log.

The posix_log_full_status member is only meaningful if the log-full-policy attribute is either POSIX_TRACE_UNTIL_FULL or POSIX_TRACE_LOOP.

For an active trace stream without log, that is created by the posix_trace_create() function, the posix_log_overrun_status member shall be set to POSIX_TRACE_NO_OVERRUN and the posix_log_full_status member shall be set to POSIX_TRACE_NOT_FULL.

posix_trace_event_info Structure

The trace event structure posix_trace_event_info contains the information for one recorded trace event. This structure is returned by the set of functions posix_trace_getnext_event(), posix_trace_timedgetnext_event(), and posix_trace_trygetnext_event().

The posix_trace_event_info structure defined in <trace.h> shall contain at least the following members:

Member Type Member Name Description
trace_event_id_t posix_event_id Trace event type identification.
pid_t posix_pid Process ID of the process that generated the trace event.
void * posix_prog_address Address at which the trace point was invoked.
int posix_truncation_status Status about the truncation of the data associated with this trace event.
struct timespec posix_timestamp Time at which the trace event was generated.

In addition, if the Trace option and the Threads option are both supported, the posix_trace_event_info structure defined in <trace.h> shall contain the following additional member:

Member Type Member Name Description
pthread_t posix_thread_id Thread ID of the thread that generated the trace event.

The posix_event_id member represents the identification of the trace event type and its value is not directly defined by the user. This identification is returned by a call to one of the following functions: posix_trace_trid_eventid_open(), posix_trace_eventtypelist_getnext_id(), or posix_trace_eventid_open(). The name of the trace event type can be obtained by calling posix_trace_eventid_get_name().

The posix_pid is the process identifier of the traced process which generated the trace event. If the_posix_event_id_ member is one of the implementation-defined system trace events and that trace event is not associated with any process, the posix_pid member shall be set to zero.

For a user trace event, the posix_prog_address member is the process mapped address of the point at which the associated call to the posix_trace_event() function was made. For a system trace event, if the trace event is caused by a system service explicitly called by the application, the posix_prog_address member shall be the address of the process at the point where the call to that system service was made.

The posix_truncation_status member defines whether the data associated with a trace event has been truncated at the time the trace event was generated, or at the time the trace event was read from the trace stream, or (if the Trace Log option is supported) from the trace log (see the event argument from the posix_trace_getnext_event() function). The _posix_truncation_status_member shall have one of the following values defined by manifest constants in the <trace.h> header:

POSIX_TRACE_NOT_TRUNCATED

All the traced data is available.

POSIX_TRACE_TRUNCATED_RECORD

Data was truncated at the time the trace event was generated.

POSIX_TRACE_TRUNCATED_READ

Data was truncated at the time the trace event was read from a trace stream or a trace log because the reader's buffer was too small. This truncation status overrides the POSIX_TRACE_TRUNCATED_RECORD status.

The posix_timestamp member shall be the time at which the trace event was generated. The clock used is implementation-defined, but the resolution of this clock can be retrieved by a call to the posix_trace_attr_getclockres() function.

If the Threads option is supported in addition to the Trace option:

Otherwise, this member is undefined.

Trace Stream Attributes

Trace streams have attributes that compose the posix_trace_attr_t trace stream attributes object. This object shall contain at least the following attributes:

In addition, if the Trace option and the Trace Inherit option are both supported, the posix_trace_attr_t trace stream creation attributes object shall contain at least the following attributes:

In addition, if the Trace option and the Trace Log option are both supported, the posix_trace_attr_t trace stream creation attributes object shall contain at least the following attribute:

2.11.2 Trace Event Type Definitions

System Trace Event Type Definitions

The following system trace event types, defined in the <trace.h> header, track the invocation of the trace operations:

The following system trace event types, defined in the <trace.h> header, report operational trace events:

The interpretation of a trace stream or a trace log by a trace analyzer process relies on the information recorded for each trace event, and also on system trace events that indicate the invocation of trace control operations and trace system operational trace events.

The POSIX_TRACE_START and POSIX_TRACE_STOP trace events specify the time windows during which the trace stream is running.

The POSIX_TRACE_FILTER trace event indicates that a trace event type filter value changed while the trace stream was running.

The POSIX_TRACE_ERROR serves to inform the analyzer process that an implementation-defined internal error of the trace system occurred.

The POSIX_TRACE_OVERFLOW trace event shall be reported with a timestamp equal to the timestamp of the first trace event overwritten. This is an indication that some generated trace events have been lost.

The POSIX_TRACE_RESUME trace event shall be reported with a timestamp equal to the timestamp of the first valid trace event reported after the overflow condition ends and shall be reported before this first valid trace event. This is an indication that the trace system is reliably recording trace events after an overflow condition.

Each of these trace event types shall be defined by a constant trace event name and a trace_event_id_t constant; trace event data is associated with some of these trace events.

If the Trace option is supported and the Trace Event Filter option and the Trace Log option are not supported, the following predefined system trace events in Trace Option: System Trace Events shall be defined:

Table: Trace Option: System Trace Events

Event Name Constant Associated Data
_
Data Type
posix_trace_error POSIX_TRACE_ERROR error
_
int
posix_trace_start POSIX_TRACE_START None.
posix_trace_stop POSIX_TRACE_STOP auto
_
int
posix_trace_overflow POSIX_TRACE_OVERFLOW None.
posix_trace_resume POSIX_TRACE_RESUME None.

If the Trace option and the Trace Event Filter option are both supported, and if the Trace Log option is not supported, the following predefined system trace events in Trace and Trace Event Filter Options: System Trace Eventsshall be defined:

Table: Trace and Trace Event Filter Options: System Trace Events

Event Name Constant Associated Data
_
Data Type
posix_trace_error POSIX_TRACE_ERROR error
_
int
posix_trace_start POSIX_TRACE_START event_filter
_
trace_event_set_t
posix_trace_stop POSIX_TRACE_STOP auto
_
int
posix_trace_filter POSIX_TRACE_FILTER old_event_filter
new_event_filter
_
trace_event_set_t
posix_trace_overflow POSIX_TRACE_OVERFLOW None.
posix_trace_resume POSIX_TRACE_RESUME None.

If the Trace option and the Trace Log option are both supported, and if the Trace Event Filter option is not supported, the following predefined system trace events in Trace and Trace Log Options: System Trace Events shall be defined:

Table: Trace and Trace Log Options: System Trace Events

Event Name Constant Associated Data
_
Data Type
posix_trace_error POSIX_TRACE_ERROR error
_
int
posix_trace_start POSIX_TRACE_START None.
posix_trace_stop POSIX_TRACE_STOP auto
_
int
posix_trace_overflow POSIX_TRACE_OVERFLOW None.
posix_trace_resume POSIX_TRACE_RESUME None.
posix_trace_flush_start POSIX_TRACE_FLUSH_START None.
posix_trace_flush_stop POSIX_TRACE_FLUSH_STOP None.

If the Trace option, the Trace Event Filter option, and the Trace Log option are all supported, the following predefined system trace events in Trace, Trace Log, and Trace Event Filter Options: System Trace Events shall be defined:

Table: Trace, Trace Log, and Trace Event Filter Options: System Trace Events

Event Name Constant Associated Data
_
Data Type
posix_trace_error POSIX_TRACE_ERROR error
_
int
posix_trace_start POSIX_TRACE_START event_filter
_
trace_event_set_t
posix_trace_stop POSIX_TRACE_STOP auto
_
int
posix_trace_filter POSIX_TRACE_FILTER old_event_filter
new_event_filter
_
trace_event_set_t
posix_trace_overflow POSIX_TRACE_OVERFLOW None.
posix_trace_resume POSIX_TRACE_RESUME None.
posix_trace_flush_start POSIX_TRACE_FLUSH_START None.
posix_trace_flush_stop POSIX_TRACE_FLUSH_STOP None.
User Trace Event Type Definitions

The user trace event POSIX_TRACE_UNNAMED_USEREVENT is defined in the <trace.h> header. If the limit of per-process user trace event names represented by {TRACE_USER_EVENT_MAX} has already been reached, this predefined user event shall be returned when the application tries to register more events than allowed. The data associated with this trace event is application-defined.

The following predefined user trace event in Trace Option: User Trace Event shall be defined:

Table: Trace Option: User Trace Event

Event Name Constant
posix_trace_unnamed_userevent POSIX_TRACE_UNNAMED_USEREVENT

2.11.3 Trace Functions

The trace interface is built and structured to improve portability through use of trace data of opaque type. The object-oriented approach for the manipulation of trace attributes and trace event type identifiers requires definition of many constructor and selector functions which operate on these opaque types. Also, the trace interface must support several different tracing roles. To facilitate reading the trace interface, the trace functions are grouped into small functional sets supporting the three different roles:


UNIX ® is a registered Trademark of The Open Group.
POSIX ® is a registered Trademark of The IEEE.
[ Main Index | XBD | XCU | XSH | XRAT]