[PATCH v3 2/3] The -z and -Z options print only successful and failing syscalls respectively. However, failure of syscall is only known after syscall return. Thus, we end up with something like this on, e.g., ENOENT:

[Dmitry V. Levin]

On Fri, Jun 07, 2019 at 11:20:35AM +0200, Paul Chaignon wrote:
> There's still one case I'm not quite sure how to handle.  For example, for
> one test case I wrote, I have the following output (a child thread execves
> a sleeping leader):
> 
>   $ strace -f -eexit,execve,nanosleep ./status-exited >/dev/null
>   execve("./status-exited", ["./status-exited"], 0x7fff54e81920 /* 65 vars */) = 0
>   strace: Process 8831 attached
>   [pid  8830] nanosleep({tv_sec=123, tv_nsec=0},  <unfinished ...>
>   [pid  8831] nanosleep({tv_sec=0, tv_nsec=12345}, NULL) = 0
>   [pid  8831] execve("./status-exited", ["./status-exited", "0"], NULL <unfinished ...>
>   [pid  8830] <... nanosleep resumed> <unfinished ...>) = ?
>   +++ superseded by execve in pid 8831 +++
>   <... execve resumed>)                   = 0
>   +++ exited with 0 +++
> 
> We won't know the status of the second execve call until it is resumed.
> In the case of a shared log, we either have to decide whether we want to
> print the unfinished execve call before knowing its status or we need to
> print syscalls out of order.
> 
> I don't think the out-of-order solution is a good idea as it would be very
> misleading to the user.  But I also don't know how to process unfinished
> syscalls...

In -z/-Z mode we are waiting for syscall exiting to decide whether to print it
or not.  This effectively means that in case of shared logs the order of
printed syscalls might differ from the regular non-z/-Z mode.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20190607/4016b967/attachment.bin>