Re: Why return probes of some syscalls sometimes are not called?

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 9 Mar 2017 15:30:42 +0000
"Dorau, Lukasz" <lukasz.dorau@intel.com> wrote:

> On Thursday, March 9, 2017 4:21 PM Steven Rostedt wrote:
> > On Thu, 9 Mar 2017 15:01:38 +0000 (UTC)
> > Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> > 
> >   
> > > Another more likely scenario is if a multithreaded process
> > > has many threads blocked (e.g. on a futex), and one of the threads
> > > exits cleanly or forks. I suspect the kernel will just tear down the
> > > other threads without hitting syscall exit.  
> > 
> > Maybe, if this happens multiple times, it could cause those kinds of
> > numbers. A fork was done zero times according to the numbers. Maybe
> > exit should be measured too.
> >   
> 
> I have run the test again with exit:
> 
> Results (60 sec):
> futex:       p 2968     r 401      (86% did not return (2567))
> poll:        p 13251    r 3957     (70% did not return (9294))
> epoll_wait:  p 1485     r 556      (62% did not return (929))
> select:      p 8063     r 8066     (OK)
> fork:        p 0        r 0        (OK)
> vfork:       p 4        r 4        (OK)
> clone:       p 6962     r 6962     (OK)
> exit:        p 3        r 0        (100% did not return (3))

I expected exit not to have a return, that's the property of exit. But
it shows that the above poll and friends is not because of exit and
fork.

Can you change your script to use syscall tracepoints instead of
retprobes?

-- Steve

> mmap:        p 71740    r 71740    (OK)
> open:        p 43822    r 43825    (OK)
> close:       p 79805    r 79806    (OK)
> write:       p 31080    r 31078    (0% did not return (2))
> read:        p 108456   r 108449   (0% did not return (7))
> 
> Lukasz