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 <[email protected]> wrote:
>
> On 2/13/19 9:45 AM, enh wrote:
> >
> >
> > On Wed, Feb 13, 2019, 03:53 Rob Landley <[email protected]
> > <mailto:[email protected]> 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
_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net
