Bug #627
closed'lttng list -u -f' behaves oddly when providers register different payloads
100%
Description
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.