[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:

[Paul Chaignon]

On Tue, Jun 04, 2019 at 12:31AM, Dmitry V. Levin wrote:
> On Sun, Jun 02, 2019 at 10:42:01PM +0200, Paul Chaignon wrote:
> > On Wed, May 22, 2019 at 12:13 PM Dmitry V. Levin <ldv at altlinux.org> wrote:
> > >
> > > On Mon, May 13, 2019 at 04:00:31PM +0000, Kohl, Burkhard wrote:
> > > [...]
> > > > > > diff --git a/strace.1.in b/strace.1.in index 76a74119..6ab95836 100644
> > > > > > --- a/strace.1.in
> > > > > > +++ b/strace.1.in
> > > > > > @@ -771,6 +771,13 @@ Print unabbreviated versions of environment, stat, termios, etc.
> > > > > >  calls.  These structures are very common in calls and so the default
> > > > > > behavior displays a reasonable subset of structure members.  Use  this
> > > > > > option to get all of the gory details.
> > > > > > +.TP
> > > > > > +.B \-z
> > > > > > +Print successful syscalls only.
> > > > >
> > > > > It might be better to be precise here regarding what we mean by "successful" exactly.  Maybe "Print only
> > > > > syscalls that did not return an error code"?
> > > >
> > > > Seems there are 3 possible outcomes for a syscall:
> > > > - zero/successful
> > > > - non-zero/not successful
> > > > - void
> > >
> > > Strictly speaking, there are more than 3 possible outcomes for a syscall:
> > > - syscall returns with an error
> > > - syscall returns without an error
> > > - syscall returns but strace fails to fetch error status (see e.g. <unavailable>)
> > > - syscall does not return because of PTRACE_EVENT_EXIT (see print_event_exit)
> > > - syscall does not return because of process disappearance (e.g. due to execve in a neighbour thread)
> > 
> > Wouldn't execve in a neightbour thread result in PTRACE_EVENT_EXIT? Are
> > the exited and unfinished cases really different?
> > 
> > It looks like PTRACE_O_TRACEEXIT is set in all cases (both PTRACE_SEIZE
> > and PTRACE_ATTACH), so when a neighbour thread does an execve, the tracee
> > thread should be torn down and stopped with PTRACE_EVENT_EXIT before
> > actual death. What am I missing?
> 
> Yes, your interpretation seems to be correct.  If I'm not mistaken,
> we even rely on this behaviour in one of strace tests.
> 
> Nevertheless, I'm pretty sure processes can be killed in a way that would
> look like disappearance.

I thought SIGKILL would be such a case.  The ptrace man page does mention
PTRACE_EVENT_EXIT shouldn't happen in case of SIGKILL.  However, it also
mentions that there's currently a bug:

  A SIGKILL signal may still cause a PTRACE_EVENT_EXIT stop before actual
  signal death.  This may be changed in the future; SIGKILL is meant to
  always immediately kill tasks even under ptrace.  Last confirmed on
  Linux 3.13.

I was able to confirm the bug under Linux 5.1...

I also checked tests/threads-execve.c which tests different behaviors
under execve.  All such behaviors seem to be covered by the exited status
already.  Any other tests/functions(/signals?) I should look into that you
think highlight the disappearance case?

> 
> 
> -- 
> ldv