[Toybox] [PATCH] sed: fix endless loop in "b loop" test.

[enh]

so...

/tmp$ cat x.c
#include <signal.h>
#include <stdio.h>

int main() {
 printf("SIG_DFL=%p SIG_IGN=%p\n", SIG_DFL, SIG_IGN);
 printf("%p\n", signal(SIGPIPE, SIG_DFL));
 printf("%p\n", signal(SIGPIPE, SIG_DFL));
 return 0;
}


on my badly-behaving (work) machines with 4.19.12 kernels and bash 4.4.12:

/tmp$ ./x
SIG_DFL=(nil) SIG_IGN=0x1
0x1
(nil)
/tmp$

whereas on my personal machine with 4.15.0 and bash 4.4.19 i get the expected:

/tmp$ ./x
SIG_DFL=(nil) SIG_IGN=0x1
(nil)
(nil)
/tmp$

so that version of bash is screwing up the default disposition of
SIGPIPE for its children?

(it's the only version of bash i've ever used that corrupts its own
history file, so i'm prepared to believe it's officially the worst
bash release ever...)

On Wed, Feb 13, 2019 at 8:03 AM Rob Landley <rob at landley.net> wrote:
>
> On 2/13/19 9:45 AM, enh wrote:
> >
> >
> > On Wed, Feb 13, 2019, 03:53 Rob Landley <rob at landley.net
> > <mailto:rob at landley.net> wrote:
> >
> >     On 2/12/19 11:48 PM, enh via Toybox wrote:
> >     > Very few places actually check for errors from emit, and I actually see
> >     > the same endless loop from "sed (GNU sed) 4.4" on current Debian, so I'm
> >     > not sure this isn't Broken As Designed, but an endless loop spewing
> >     > "short write" (or saying nothing, in the case of GNU sed) really doesn't
> >     > feel like useful behavior in face of EPIPE, which really isn't going to
> >     > fix itself. Certainly not being able to run the sed tests to completion
> >     > is pretty annoying --- which is why, unless we remove this test as
> >     > invalid, we should probably also add a SKIP_HOST=1 to the "b loop" test.
> >     >
> >     > Note that even with this fix you'll see the error twice:
> >     >
> >     >   sed: short write: Broken pipe
> >     >   sed: short write: Broken pipe
> >
> >     I'm not seeing this error, make test_sed currently runs to completion
> >     successfully for me? (Applied anyway, but how do I trigger what you're seeing in
> >     toybox? We don't seem to have that test in sed.tests?)
> >
> >
> > Yeah, you do, it's the one called "b loop". I mentioned it on the list when it
> > started happening. It's been completely reproducible for me on Debian for months
> > now, but it did seem to come from nowhere.
> >
> > As I discovered last night, it's actually affecting GNU sed too, which strace
> > shows just ignoring EPIPE from write(2) over and over. What happens for you
> > (before this patch)? Death by SIGPIPE?
>
> PASS: sed prodigaler newline
> PASS: sed aci
> PASS: sed b loop
> PASS: sed b skip
> PASS: sed b end
>
> I suspect a kernel upgrade changed tty/signal behavior? Still running Ubuntu
> 14.04. (I know, I know...)
>
> Rob