[PATCH v4 1/4] Option to print only failing syscalls
paul.chaignon at gmail.com
Tue Jun 18 11:55:15 UTC 2019
On Tue, Jun 18, 2019 at 02:12:42PM +0300, Dmitry V. Levin wrote:
> On Tue, Jun 18, 2019 at 10:18:10AM +0000, Kohl, Burkhard wrote:
> > I created 5 different trace files ("*.trc") with the prefix reflecting the respective
> > combination of flags used, i.e.:
> > ./strace -tfv -o nozorZ.trc /usr/bin/time -v sleep 1
> > ./strace -tfvzZ -o zZ.trc /usr/bin/time -v sleep 1
> > ./strace -tfvZz -o Zz.trc /usr/bin/time -v sleep 1
> > ...
> > Line count clearly shows that the output of both -zZ/-Zz variants differ.
> Thanks, this is indeed a bug: after the third patch -zZ effectively means
> the same as -Z, and -Zz means the same as -z.
> Paul, this happens because each qualify("status=set") invocation
> re-initializes status_set.
Thanks Burkhard for testing and spotting this!
I thought strace -estatus=x -estatus=y would be the same as
strace -estatus=x,y. My bad.
I'm not quite sure how to fix this though. Should -zZ mean
-estatus=failed,successful or should it be forbidden? If we allow these
two options to be combined, we have to consider the -estatus=detached -Z
case too: should it mean -estatus=detached,failed or should it behave as
if we had -estatus=detached -estatus=failed?
I tend to think we should print a warning in -zZ case (e.g., "z option
overwritten by Z option"), so that -z/-Z behave exactly as
-estatus=successful/-estatus=failed. They are meant to be quick aliases
anyway; more complex filters should be expressed with -estatus.
More information about the Strace-devel