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@xxxxxxxxxx> > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
