Bug #516
closedenable-event --filter error reporting is misleading
100%
Description
Ericsson, myself, and Christian stumbled on this issue, and each of us thought it was a bug, while it was indeed a bad usage. We have two things here: the default behavior of enable-event (without -c parameter) is to create a "default" channel, even if a channel has already been created. The second issue is a misleading error message.
First, when a --buffers-uid channel has been created in a session, we should probably then use --buffers-uid as default buffer type, else the enable-command fails without -c parameter.
We might also want to consider that enable-event command performed after an enable-channel command, should probably not spawn a default channel, because this is unexpected.
Also, this failure scenario is misleading:
512 lttng create 513 lttng enable-channel -u --buffers-uid test 514 lttng enable-event -u -a --filter '$ctx.procname=="abc"' Ret filter: -24 Error: Setting filter: '$ctx.procname=="abc"'
It leads the user to think that there is something wrong with the filter expression, while in fact it's the default channel that has the wrong buffer type (pid buffers).
So both the error message and the behavior should be fixed here I think.
Updated by David Goulet over 11 years ago
- Status changed from New to Confirmed
- Priority changed from Critical to High
Updated by David Goulet over 11 years ago
- Status changed from Confirmed to Resolved
- % Done changed from 0 to 100
Applied in changeset 8571134087a7a1fbd83924ab5b98836ce6ca840a.