[PATCH 2/4] nptl: Handle EPIPE on tst-cancel2

Florian Weimer fweimer@redhat.com
Tue Aug 20 10:23:00 GMT 2019


* Adhemerval Zanella:

> The SIGPIPE can be handled before SIGCANCEL, which makes write fail
> and the thread return a non expected result.
>
> Checked on x86_64-linux-gnu.
>
> 	* nptl/tst-cancel2.c (tf): Do not abort with EPIPE.
> ---
>  nptl/tst-cancel2.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/nptl/tst-cancel2.c b/nptl/tst-cancel2.c
> index 1f0429d343..632ea4e0ae 100644
> --- a/nptl/tst-cancel2.c
> +++ b/nptl/tst-cancel2.c
> @@ -20,6 +20,7 @@
>  #include <signal.h>
>  #include <stdio.h>
>  #include <unistd.h>
> +#include <errno.h>
>  
>  
>  static int fd[2];
> @@ -32,7 +33,14 @@ tf (void *arg)
>       write blocks.  */
>    char buf[100000];
>  
> -  while (write (fd[1], buf, sizeof (buf)) > 0);
> +  while (1)
> +    {
> +      /* Ignore EPIPE errors for case the SIGPIPE is handle before
> +	 SIGCANCEL.  */
> +      ssize_t ret = write (fd[1], buf, sizeof (buf));
> +      if (ret == 0 || (ret == -1 && errno != EPIPE))
> +       break;
> +    }
>  
>    return (void *) 42l;
>  }

I disagree with this change.  SIGPIPE does not appear to be a valid
error from write in this test because the thread is canceled before the
read end of the pipe is closed.  POSIX says this:

| The cancellation processing in the target thread shall run
| asynchronously with respect to the calling thread returning from
| pthread_cancel().

But that doesn't mean that the thread can observe actions in its
uncanceled state that happen after the cancellation, which is the case
when the write fails with SIGPIPE.

Thanks,
Florian



More information about the Libc-alpha mailing list