LTTng » LTTng-tools

(Filing this bug report as per Mathieu Desnoyers's request of 6 May 2013)

A natural assumption concerning an event's "fully qualified" identifier is that it is something like session:domain:channel:name. Tracepoints and syscalls have system-defined names, and of course the domain can only be 'kernel' or 'userspace', but everything else is pretty much arbitrary. It follows thus that, as long as they're in different channels (or domains or possibly sessions), two events may bear the same name even though they represent completely different occurrences.

But that's not what lttng seems to be doing.

Here's what I did (lttng list output has been abridged), with comments interspersed:

$ sudo -H lttng create asession
Session asession created.
Traces will be written in /root/lttng-traces/asession-20130214-145626
$ sudo -H lttng enable-event sched_switch -k --tracepoint
kernel event sched_switch created in channel channel0
$ sudo -H lttng enable-event sched_switch -k --function lttng_calibrate_kretprobe --channel channel1
Error: Event sched_switch: Enable kernel event failed (channel channel1, session asession)
Warning: Some command(s) went wrong
/*
 Okay, so maybe event names have session:domain scope. Let's test this.
 */
$ sudo -H lttng enable-event fevent -k --function lttng_calibrate_kretprobe --channel channel1
kernel event fevent created in channel channel1
$ sudo -H lttng enable-event fevent -k --function lttng_calibrate_kretprobe --channel channel2
kernel event fevent created in channel channel2
/*
 Apparently not.
 */
$ sudo -H lttng list asession
Tracing session asession: [inactive]
=== Domain: Kernel ===
- channel2: [enabled]
    Events:
      fevent (type: probe) [enabled]
        offset: 0x0
        symbol: lttng_calibrate_kretprobe
- channel1: [enabled]
    Events:
      fevent (type: probe) [enabled]
        offset: 0x0
        symbol: lttng_calibrate_kretprobe
- channel0: [enabled]
    Events:
      sched_switch (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled]
/*
 Instead of tracepoint then function, let's try function then tracepoint
 */
$ sudo -H lttng enable-event sched_process_fork -k --function lttng_calibrate_kretprobe --channel channel3
kernel event sched_process_fork created in channel channel3
$ sudo -H lttng enable-event sched_process_fork -k
kernel event sched_process_fork created in channel channel0
$ sudo -H lttng enable-event sched_process_fork -k --function lttng_calibrate_kretprobe --channel channel4
Error: Event sched_process_fork: Enable kernel event failed (channel channel4, session asession)
Warning: Some command(s) went wrong
/*
 Fascinating.
 */
$ sudo -H lttng list asession
Tracing session asession: [inactive]
- channel3: [enabled]
    Events:
      sched_process_fork (type: probe) [enabled]
        offset: 0x0
        symbol: lttng_calibrate_kretprobe
- channel2: [enabled]
    Events:
      fevent (type: probe) [enabled]
        offset: 0x0
        symbol: lttng_calibrate_kretprobe
- channel1: [enabled]
    Events:
      fevent (type: probe) [enabled]
        offset: 0x0
        symbol: lttng_calibrate_kretprobe
- channel0: [enabled]
    Events:
      sched_process_fork (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled]
      sched_switch (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled]

At this point it looks like defining a kernel tracepoint prevents that tracepoint's name from being used in other channels to define other events (or even the same event). But nothing apparently prevents these other events from being set up before the tracepoint. (Not shown here is the case where a tracepoint is defined in one channel, and then in another: the second tracepoint event definition fails as well)

(Note that I haven't even tried yet to see what happens between simultaneous sessions...)

The control flow of the error-causing commands is something like:

• event.c's event_kernel_enable_tracepoint returns LTTNG_ERR_KERN_ENABLE_FAIL because
• kernel.c's kernel_create_event gets something else than ENOSYS or EEXIST from
• kernel-ctl.c's kernctl_create_event.
• Beyond kernctl_create_event is debugfs, inside of which occurs...whatever.