Bug #343 closed
When enable-event with invalid filter, error is given but the event is still enabled
Added by Tan le tran over 12 years ago.
Updated over 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