Comment 8 for bug 1410673

------- Comment From <email address hidden> 2015-02-02 03:15 EDT-------
(In reply to comment #25)
> It appears that all fds get POLLHUP and hence get filtered out
> by the perf_evlist__filter_pollfd(evlist, POLLERR|POLLHUP), check.
> This happens most of the time but not always. When this happens
> the mmap is freed (in perf_evlist__munmap_filtered()), but then we
> do the "goto again" which tries to read from the freed mmap.
>
> With the following patch, I was able to run the 'perf trace sleep 1'
> several hundred times, but this defeats the purpose of the "draining"
> check.
>
>
> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
> index fb12645..ac25e16 100644
> --- a/tools/perf/builtin-trace.c
> +++ b/tools/perf/builtin-trace.c
> @@ -2173,8 +2173,10 @@ next_event:
> int timeout = done ? 100 : -1;
>
> if (!draining && perf_evlist__poll(evlist, timeout) > 0) {
> - if (perf_evlist__filter_pollfd(evlist, POLLERR |
> POLLHUP) == 0)
> + if (perf_evlist__filter_pollfd(evlist, POLLERR |
> POLLHUP) == 0) {
> draining = true;
> + goto out_disable;
> + }
>
> goto again;
> }
>
> Li, can you look into why they added the 'draining' check (IOW, why
> do they go back and read even if perf_evlist___filter_pollfd() returns
> 0 ?

Sure, still looking at this and your discussion with community. :)

>
> It maybe interesting to see if the mainline code, which at a quick
> glance seems similar to this code in Ubuntu Vivid, behaves the same
> way on this system.