LTTng » LTTng-tools

LTTng (including babeltrace) can handle simultaneous multiple same-name event definitions, but list -u -f lists the events incorrectly if the two conflicting definitions are contiguous in the listing. An example will make this clear:

$ lttng list -u -f
UST events:
-------------
None

$ lttng list -u -f
UST events:
-------------

PID: 6185 - Name: ./simple
      sample_component:message (loglevel: TRACE_NOTICE (5)) (type: tracepoint)
        field: floatfield (float)

$ lttng list -u -f
UST events:
-------------

PID: 6190 - Name: ./sample
      sample_component:message (loglevel: TRACE_WARNING (4)) (type: tracepoint)
        field: message (string)

PID: 6185 - Name: ./simple
        field: floatfield (float)

$ lttng list -u -f
UST events:
-------------

PID: 6290 - Name: ./sample
      sample_component:message (loglevel: TRACE_WARNING (4)) (type: tracepoint)
        field: message (string)

PID: 6200 - Name: ./complex
      sample_component:silly (loglevel: TRACE_WARNING (4)) (type: tracepoint)
        field: intfield (integer)

PID: 6185 - Name: ./simple
      sample_component:message (loglevel: TRACE_NOTICE (5)) (type: tracepoint)
        field: floatfield (float)

$ lttng list -u -f
UST events:
-------------

PID: 6210 - Name: ./complex
      sample_component:silly (loglevel: TRACE_WARNING (4)) (type: tracepoint)
        field: intfield (integer)

PID: 6190 - Name: ./sample
      sample_component:message (loglevel: TRACE_WARNING (4)) (type: tracepoint)
        field: message (string)

PID: 6185 - Name: ./simple
        field: floatfield (float)

$ lttng list -u -f
UST events:
-------------

PID: 6310 - Name: ./complex
      sample_component:silly (loglevel: TRACE_WARNING (4)) (type: tracepoint)
        field: intfield (integer)

PID: 6295 - Name: ./simple
      sample_component:message (loglevel: TRACE_NOTICE (5)) (type: tracepoint)
        field: floatfield (float)

PID: 6290 - Name: ./sample
        field: message (string)

$ lttng list -u -f
UST events:
-------------

PID: 6642 - Name: ./simple
      sample_component:message (loglevel: TRACE_NOTICE (5)) (type: tracepoint)
        field: floatfield (float)

PID: 6635 - Name: ./sample
        field: message (string)

PID: 6630 - Name: ./simple
        field: floatfield (float)

As can be seen above, the sample and simple processes use conflicting payload definitions for the user-space event sample_component:message. The two (or more) lists of fields are displayed in all cases, but if the sample and simple blocks are contiguous in the lttng list -u -f output, the second process loses its event definition line (also the third process, etc.). Note how having some other process between sample and simple prevents this. Note also how it does not matter which of sample and simple appears first in the listing.

This should not happen. A process's list of events and their fields should be independent of the other processes' lists.

In particular, this bug of the current implementation means the loglevel of the obscured process' event is not recoverable from the listing.

An oddity of the implementation of lttng list -u -f is that within a given event, the order of the fields is reversed with respect to the TP_ARGS macro used to define them. For instance, TP_ARGS(char *, text, float, floatvalue) will yield:

UST events:
-------------

PID: 6310 - Name: ./complex
      sample_component:silly (loglevel: TRACE_WARNING (4)) (type: tracepoint)
        field: floatfield (float)
        field: message (string)

This second observation is not really a bug, just a minor cosmetic issue: after designing a tracepoint provider's events, one expects their payload fields to be listed in the same order as in the code.