Bug #959
closedEvent status incorrect after load
100%
Description
We have found a bug in LTTng regarding state of events after loading saved session configuration.
Steps to reproduce:
This requires a LTTng test application (hello-tp.h, hello-tp.c and hello.c) which can be found on LTTng web site: http://lttng.org/docs/#doc-tracing-your-own-user-application
1) Start test application
2) lttng create s1
3) lttng enable-event -u -s s1 hello_world:my_first_tracepoint -f '$ctx.procname "hello*"'
4) lttng enable-event -u -s s1 -c channel0 hello_world:my_first_tracepoint
5) lttng disable-event -u -s s1 -c channel0 -a
6) lttng enable-event -u -s s1 -c channel0 hello_world:my_first_tracepoint
7) lttng list s1
Tracing session s1: [inactive]
Trace path: /root/lttng-traces/s1-20000101-223220
Live timer interval (usec): 0
Buffer type: per UID
Channels:
-------------
- channel0: [enabled]
Attributes:
overwrite mode: 0
subbufers size: 131072
number of subbufers: 4
switch timer interval: 0
read timer interval: 0
trace file count: 0
trace file size (bytes): 0
output: mmap()
Events:
hello_world:my_first_tracepoint (type: tracepoint) [enabled]
hello_world:my_first_tracepoint (type: tracepoint) [disabled] [with filter]
Note that first event is enabled which is correct.
8) lttng save
9) lttng destroy
10) lttng load
11) lttng list s1
Tracing session s1: [inactive]
Trace path: /root/lttng-traces/s1-20000101-223220
Live timer interval (usec): 0
=== Domain: UST global ===
Buffer type: per UID
Channels:
-------------
- channel0: [enabled]
Attributes:
overwrite mode: 0
subbufers size: 131072
number of subbufers: 4
switch timer interval: 0
read timer interval: 0
trace file count: 0
trace file size (bytes): 0
output: mmap()
Events:
hello_world:my_first_tracepoint (type: tracepoint) [disabled] [with filter]
hello_world:my_first_tracepoint (type: tracepoint) [disabled]
Bug! All events are disabled!
Updated by Jonathan Rajotte Julien about 9 years ago
- Status changed from New to Confirmed
- Target version set to 2.8
Hi,
Thanks for the good bug report! I've confirmed it on HEAD.
It come from the fact that for now we only disable ust event by a name basis so in this case the disable action is done afterward based on the event name which disable both events since they have the same name. It is a known limitation and we are working on it.
Cheers!
Updated by Jonathan Rajotte Julien about 9 years ago
- Status changed from Confirmed to Feedback
Updated by Li Liguang about 9 years ago
Hi,
This bug can't be reproduced with those modification. So you can close this issue.
Regards
Updated by Jérémie Galarneau over 8 years ago
- Status changed from Feedback to Confirmed
- Assignee set to Jérémie Galarneau
Updated by Jonathan Rajotte Julien over 8 years ago
- Status changed from Confirmed to Resolved
- % Done changed from 0 to 100
Applied in changeset tools|commit:d7b645e2c77977a8a83362f27094bf6d126f6fb8.