Bug #343
closed
When enable-event with invalid filter, error is given but the event is still enabled
Added by Tan le tran about 12 years ago.
Updated about 12 years ago.
Description
Scenario:
=========
1)_ lttng create ses1 -o /cluster/temp/sessiondir/ses1
2)_ lttng enable-event ust_tests_demo2:loop -u --filter ' intfield => 2 '
get:
error syntax error
Parse error
Error: Error setting filter
3)_ lttng list ses1
get:
:
Events:
ust_tests_demo2:loop (type: tracepoint) [enabled]
Expected Behaviour:
===================
The event should not be enabled if the specified filter is invalid.
Files
|
log.txt (13.5 KB)
log.txt |
Terminal log with "sessiond -vvv" |
Tan le tran, 09/18/2012 05:08 PM
|
|
The above issue has been observed with the following commits:
userspace : (Thu Sep 6 ) a5a9f42 Ensure that read-side functions meet 10-line LGPL criterion
lttng-ust : (Tue Sep 18) 5d3bc5e Fix: get_wait_shm() ust mutex deadlock (add 2 missing exit calls)
lttng-tools:(Tue Sep 18) 4adabd6 Fix: Remove LPOLLNVAL from consumer metadata revents
babeltrace: (Thu Sep 13) f546472 Fix: Documentation cleanup
- Project changed from LTTng-UST to LTTng-tools
- Status changed from New to Confirmed
- Assignee set to David Goulet
- Priority changed from Normal to High
- Target version set to 2.1 stable
- Status changed from Confirmed to Feedback
So actually I don't think this is an error.
Enabling an event and a filter is two different API calls so the event is first enabled successfully but the filter is wrong so the fix is simply to retry lttng enable-event with the right filter and it works.
I'm not sure I can easily disable or even delete an event on a wrong filter... Rerun the command with the correct filter is I think the correct behavior and thing to do.
Thought?
Thanks
Yes, this is a bug. This is an unexpected behavior on the command line.
If we see that setting the filter triggers an error, we should disable the event.
This is an issue at the command line level, not at the API level.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I'm not sure to be honest.
There is a use case where enabling let say event ust-eventA, tracing
and then later on setting a filter on it. Disabling it seems to me a
bit harsh and not a right behavior for an already good enabled event.
David
bugs@lttng.org:
Issue #343 has been updated by Mathieu Desnoyers.
Yes, this is a bug. This is an unexpected behavior on the command
line.
If we see that setting the filter triggers an error, we should
disable the event.
This is an issue at the command line level, not at the API level.
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJQXJrXAAoJEELoaioR9I02zKIH/3pLValBcrJPrnRjEwjjL2Kw
r04j9J9UH93w+fEU0nl485JGphsEG/htOA73QRJUFKwgHP9vY6+iL96QUh2apPWf
QNgH0oz3rIb2orFEc0UtEiWxHvoAQMfPTu2B7xgj1mFDJyvIBVfZ1FGuhQyPzdqD
8bl4jCaMeHVZVAsQt931ySsXwHOFlkSS6bc+EOU+VgdKrvSw0TtkOQCSce6csWXT
jWkyUAoBc0DxM00h5eerBQNY8jpdrYQ83d79x9vEJKTlUtVdKwSIRUTdtmTSpm4/
N8AljAEjlyHDo4VvrNuj6qkIke+OqIbp7R4OQ3jcdL6ws5upzNEmMh5QPWzbBCg=
=qThR
-----END PGP SIGNATURE-----
That's a case where there has been a reported error when setting up the filter. It's OK to be harsh and disable a previously enabled event in that kind of condition. You might want to let the user know that the event id disabled due to the filter error.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I guess we could simply do a lttng_disable_event if an error
occured... that makes sense to me.
I'll keep this bug alive and fix this for 2.1-stable.
Thanks
David
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJQXJ90AAoJEELoaioR9I0227AIAKTxM2IvOMMql7PsbzCLG99E
l7ZumDeXvm8BiR/zVXYqeLiMdWo6ACbhkfO+TivxyIyiqfZeTkR4WxX7NzInOSc6
4gA2WkmzqC8932xakPtbiHtWHaShLQdCYttEoj/Is6UIgbBxGHubZy+IQoCl/HT4
FouUnE03tjFK360voTiE75rqFdJSWR+PWYVnJb7rhOyQQEPA3kpwBbp9UNPYF2qE
5kO9u2Ak4RbOaZ/RYFc0mObkN6rtWx9QrXx6l6FeYtlRRw1/c32MR+3XWPxE2mph
XB3Kmrhyx40MdmlZlHRy7S2TM0YZi24KFJMVWTLwljtqmmyZRZLmJ0vlQM7/p1k=
=nL3H
-----END PGP SIGNATURE-----
- Status changed from Feedback to Confirmed
- Status changed from Confirmed to Resolved
- % Done changed from 0 to 100
Also available in: Atom
PDF