All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers3@gmail.com>
To: Eryu Guan <eguan@redhat.com>
Cc: fstests@vger.kernel.org, Eric Biggers <ebiggers@google.com>
Subject: Re: [PATCH] generic/397: be compatible with ignored SIGPIPE
Date: Tue, 13 Jun 2017 10:38:56 -0700	[thread overview]
Message-ID: <20170613173856.GA119255@gmail.com> (raw)
In-Reply-To: <20170613065438.GA4788@eguan.usersys.redhat.com>

Hi Eryu,

On Tue, Jun 13, 2017 at 02:54:38PM +0800, Eryu Guan wrote:
> On Mon, Jun 12, 2017 at 02:15:28PM -0700, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > If generic/397 is executed in an environment with SIGPIPE ignored, it
> > fails because the 'yes' program prints an error message:
> > 
> >     yes: standard output: Broken pipe
> >     yes: write error
> > 
> > This can be reproduced with:
> > 
> >     trap '' SIGPIPE; ./check generic/397
> > 
> > Fix it by generating the string of 255 y's using just 'head' and 'tr'
> > instead of 'yes', 'head', and 'tr'.
> > 
> > Although it's not really a good idea to execute xfstests with SIGPIPE
> > ignored, this is the only test I've noticed where it causes a problem,
> > so it might as well be fixed in the test.
> 
> I'm just curious, why do you need to run fstests with SIGPIPE ignored?
> 

It's more of an accidental thing, and I'm likely still going to fix the specific
case I encountered where 'check' was being run with SIGPIPE being ignored
(regardless of whether this xfstests patch goes in or not).  But I think it's an
easy problem for others to run into, since sometimes processes ignore SIGPIPE
because they want to get write errors instead, but then when doing fork() +
exec() they forget to reset the SIGPIPE handler.  Notably, Python got this wrong
and it wasn't fixed until Python 3, so any programs executing the 'check' script
from a Python 2 script will usually get this wrong (see:
https://bugs.python.org/issue1652).  And usually everything works fine but every
once in a while there is a weird problem like this which has to be debugged.

> 
> Using perl seems simpler, we have some other tests do similar tasks
> using perl too.
> 
> 	maxname=$($PERL_PROG -e 'print "y" x 255;')
> 

Yes, the perl version works too.

Eric

      reply	other threads:[~2017-06-13 17:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-12 21:15 [PATCH] generic/397: be compatible with ignored SIGPIPE Eric Biggers
2017-06-13  6:54 ` Eryu Guan
2017-06-13 17:38   ` Eric Biggers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170613173856.GA119255@gmail.com \
    --to=ebiggers3@gmail.com \
    --cc=ebiggers@google.com \
    --cc=eguan@redhat.com \
    --cc=fstests@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.