Project

General

Profile

Bug #627

'lttng list -u -f' behaves oddly when providers register different payloads

Added by Daniel U. Thibault almost 7 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Low
Assignee:
-
Target version:
Start date:
09/05/2013
Due date:
% Done:

100%

Estimated time:

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.


Related issues

Related to LTTng-UST - Feature #710: List event fields in the same order as the TP definitionNew01/09/2014

Actions
#1

Updated by David Goulet almost 7 years ago

  • Status changed from New to Confirmed

I'm pretty sure this is an issue in the lttng command line especially in src/bin/lttng/commands/list.c in function list_ust_event_fields().

I'll have to investigate with the person who did the code and find a reasonable fix.

#2

Updated by David Goulet over 6 years ago

Pushing a fix but before this ticket get closed automatically, the issue with the order of the payload fields is now a new bug in the lttng-ust project (#710) linked to that ticket.

#3

Updated by David Goulet over 6 years ago

  • Status changed from Confirmed to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF