Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

io/eintr.t test hangs indefinitely #11149

Closed
p5pRT opened this issue Feb 22, 2011 · 33 comments
Closed

io/eintr.t test hangs indefinitely #11149

p5pRT opened this issue Feb 22, 2011 · 33 comments

Comments

@p5pRT
Copy link

p5pRT commented Feb 22, 2011

Migrated from rt.perl.org#84688 (status was 'resolved')

Searchable as RT84688$

@p5pRT
Copy link
Author

p5pRT commented Feb 22, 2011

From Mark.Martinec@ijs.si

Created by Mark.Martinec@ijs.si

A test io/eintr.t which is invoked at the 'make test' phase
of the Perl installation on a FreeBSD hangs indefinitely
(i.e. until interrupted manually).

Looking at the io/eintr.t more closely, there are two instances
of a 'print' which never complete, and are not interrupted by
the alarm timer​:
- in the 'close during print' subtest
- in the 'die during print' subtest

If I comment out the '$st = print $out $buf' and
the '$st = eval { print $out $buf }' the io/eintr.t
finishes (with reported failures naturally).

Other that that, it seems that perl installs and runs alright,
including the remaining self-tests.

Perl Info

Flags:
    category=install
    severity=medium

Site configuration information for perl 5.13.10:

Configured by mark at Tue Feb 22 17:29:14 CET 2011.

Summary of my perl5 (revision 5 version 13 subversion 10) configuration:
   
  Platform:
    osname=freebsd, osvers=7.2-release-p2, archname=amd64-freebsd
    uname='freebsd dorothy.ijs.si 7.2-release-p2 freebsd 7.2-release-p2 #0: wed jul 15 15:45:26 cest 2009 lesi@dorothy.ijs.si:usrobjusrsrcsysdorothy amd64 '
    config_args='-sde -Dusedevel=Y -Dprefix=/usr/local -Darchlib=/usr/local/lib/perl5/5.13.10/mach -Dprivlib=/usr/local/lib/perl5/5.13.10 -Dman3dir=/usr/local/lib/perl5/5.13.10/perl/man/man3 -Dman1dir=/usr/local/man/man1 -Dsitearch=/usr/local/lib/perl5/site_perl/5.13.10/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.13.10 -Dscriptdir=/usr/local/bin -Dsiteman3dir=/usr/local/lib/perl5/5.13.10/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Ui_malloc -Ui_iconv -Uinstallusrbinperl -Dcc=cc -Duseshrplib -Dinc_version_list=none -Dccflags=-DAPPLLIB_EXP="/usr/local/lib/perl5/5.13.10/BSDPAN" -Doptimize=-O2 -fno-strict-aliasing -pipe -Ui_gdbm -Dusethreads=n -Dusemymalloc=n -Duse64bitint'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.13.10/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include',
    optimize='-O2 -fno-strict-aliasing -pipe',
    cppflags='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.13.10/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.2.1 20070719  [FreeBSD]', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -Wl,-E  -fstack-protector -L/usr/local/lib'
    libpth=/usr/lib /usr/local/lib
    libs=-lgdbm -lm -lcrypt -lutil
    perllibs=-lm -lcrypt -lutil
    libc=, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='  -Wl,-R/usr/local/lib/perl5/5.13.10/mach/CORE'
    cccdlflags='-DPIC -fPIC', lddlflags='-shared  -L/usr/local/lib -fstack-protector'

Locally applied patches:
    


@INC for perl 5.13.10:
    /usr/local/lib/perl5/5.13.10/BSDPAN
    /usr/local/lib/perl5/site_perl/5.13.10/mach
    /usr/local/lib/perl5/site_perl/5.13.10
    /usr/local/lib/perl5/5.13.10/mach
    /usr/local/lib/perl5/5.13.10
    .


Environment for perl 5.13.10:
    HOME=/root
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin
    PERL_BADLANG (unset)
    SHELL=/usr/local/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Feb 24, 2011

From @iabyn

On Tue, Feb 22, 2011 at 11​:50​:51AM -0800, Mark Martinec wrote​:

A test io/eintr.t which is invoked at the 'make test' phase
of the Perl installation on a FreeBSD hangs indefinitely
(i.e. until interrupted manually).

Looking at the io/eintr.t more closely, there are two instances
of a 'print' which never complete, and are not interrupted by
the alarm timer​:
- in the 'close during print' subtest
- in the 'die during print' subtest

Do you have the ability to run trace on the script, to see what's going on
at the OS level?

--
The Enterprise is involved in a bizarre time-warp experience which is in
some way unconnected with the Late 20th Century.
  -- Things That Never Happen in "Star Trek" #14

@p5pRT
Copy link
Author

p5pRT commented Feb 24, 2011

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Feb 24, 2011

From @Leont

On Tue, Feb 22, 2011 at 8​:50 PM, Mark Martinec
<perlbug-followup@​perl.org> wrote​:

[Please describe your issue here]

A test io/eintr.t which is invoked at the 'make test' phase
of the Perl installation on a FreeBSD hangs indefinitely
(i.e. until interrupted manually).

Looking at the io/eintr.t more closely, there are two instances
of a 'print' which never complete, and are not interrupted by
the alarm timer​:
- in the 'close during print' subtest
- in the 'die during print' subtest

If I comment out the '$st = print $out $buf' and
the '$st = eval { print $out $buf }' the io/eintr.t
finishes (with reported failures naturally).

Other that that, it seems that perl installs and runs alright,
including the remaining self-tests.

[Please do not change anything below this line]

I wouldn't be surprised if this was related to my signaling patches,
though I'd be surprised if safe signaling was broken too. It wouldn't
be the first issue on *BSD though. I may be close to grokking what's
going on…

Leon

@p5pRT
Copy link
Author

p5pRT commented Feb 25, 2011

From Mark.Martinec@ijs.si

Do you have the ability to run trace on the script, to see what's going on
at the OS level?

Here is a ktrace (or rather, its kdump -E) of a simplifield test program​:

#!/usr/bin/perl
use warnings;
use strict;

$SIG{PIPE} = 'IGNORE';
my($in,$out); pipe $in, $out;
select $out; $| = 1; select STDOUT;

$SIG{ALRM} = sub { close($out) }; # = sub { die };
my $buf = "a" x 1_000_000 . "\n";
alarm(3);
print $out $buf;

# ktrace ./0.pl
(interrupted after a minute)

# kdump -E
  (-E shows elapsed time in seconds since the program start)

[...]

51237 perl5.13.10 0.011285 CALL setitimer(0,0x7fffffffe850,0x7fffffffe830)
51237 perl5.13.10 0.011293 RET setitimer 0
51237 perl5.13.10 0.011313 CALL write(0x4,0x40e5b000,0x2000)
51237 perl5.13.10 3.011961 GIO fd 4 wrote 4096 bytes
  "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
51237 perl5.13.10 3.011989 RET write 8192/0x2000
51237 perl5.13.10 3.011994 PSIG SIGALRM caught handler=0x406c9050 mask=0x0 code=0x0
51237 perl5.13.10 3.012001 CALL sigreturn(0x7fffffffe2f0)
51237 perl5.13.10 3.012006 RET sigreturn JUSTRETURN
51237 perl5.13.10 3.012015 CALL write(0x4,0x40e5b000,0x2000)
51237 perl5.13.10 66.062540 RET write -1 errno 4 Interrupted system call
51237 perl5.13.10 66.062556 PSIG SIGINT SIG_DFL

Seting environment variable PERLIO="​:stdio" or PERLIO="​:perlio"
makes no difference.

So it looks like after the 3 second timer expires the write returns,
but is then automatically restarted.

  Mark

@p5pRT
Copy link
Author

p5pRT commented Feb 25, 2011

From @Leont

On Tue, Feb 22, 2011 at 8​:50 PM, Mark Martinec
<perlbug-followup@​perl.org> wrote​:

A test io/eintr.t which is invoked at the 'make test' phase
of the Perl installation on a FreeBSD hangs indefinitely
(i.e. until interrupted manually).

Looking at the io/eintr.t more closely, there are two instances
of a 'print' which never complete, and are not interrupted by
the alarm timer​:
- in the 'close during print' subtest
- in the 'die during print' subtest

If I comment out the '$st = print $out $buf' and
the '$st = eval { print $out $buf }' the io/eintr.t
finishes (with reported failures naturally).

Other that that, it seems that perl installs and runs alright,
including the remaining self-tests.

Can you test this again on blead?

Leon

@p5pRT
Copy link
Author

p5pRT commented Feb 25, 2011

From Mark.Martinec@ijs.si

Can you test this again on blead?

I did (git clone an hour ago), makes no difference.

One thing I previously reported incorrectly​:

Seting environment variable PERLIO="​:stdio" or PERLIO="​:perlio"
makes no difference.
... it does make a difference​:

With PERLIO="​:stdio" the simplified test case does work (aborts
after a timeout) - in both cases (die or close in the signal handler).

The io/eintr.t bails out on PERLIO="​:stdio" - but out of curiosity​:
if I comment out its "Skip stdio not supported for this script" check,
this is what comes out​:

$ PERLIO="​:stdio" ./perl -I.. -MTestInit io/eintr.t
1..10
not ok 1 - read/close​: sig handler close status
# Failed at io/eintr.t line 73
# got "nok"
# expected "ok"
ok 2 - read/close​: read status
ok 3 - read/close​: close status
ok 4 - read/die​: read status
not ok 5 - read/die​: close status
# Failed at io/eintr.t line 85
ok 6 - print/close​: sig handler close status
ok 7 - print/close​: print status
ok 8 - print/close​: close status
Died at io/eintr.t line 103.
# Looks like you planned 10 tests but ran 8.

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2011

From @tomhukins

Porters,

I tried building blead on FreeBSD 8.2 yesterday but failed due to a
problem I have bisected to​:
http​://perl5.git.perl.org/perl.git/commit/b83080de5c4254
(Increase PERLIOBUF_DEFAULT_BUFSIZ to larger of 8192 and BUFSIZ)

The problem manifests itself as the test t/io/eintr.t freezing after the
fifth test with the process in the "pipdwc" state.

If I explicitly set PERLIOBUF_DEFAULT_BUFSIZ to 4096 as described in the
commit message, this test passes and I can build perl successfully.

I'm happy to provide more information on request or run any commands
that might offer useful insight.

Tom

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2011

From @craigberry

On Thu, Mar 10, 2011 at 9​:00 AM, Tom Hukins <perlbug-followup@​perl.org> wrote​:

# New Ticket Created by  Tom Hukins
# Please include the string​:  [perl #85842]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=85842 >

Porters,

I tried building blead on FreeBSD 8.2 yesterday but failed due to a
problem I have bisected to​:
http​://perl5.git.perl.org/perl.git/commit/b83080de5c4254
(Increase PERLIOBUF_DEFAULT_BUFSIZ to larger of 8192 and BUFSIZ)

The problem manifests itself as the test t/io/eintr.t freezing after the
fifth test with the process in the "pipdwc" state.

If I explicitly set PERLIOBUF_DEFAULT_BUFSIZ to 4096 as described in the
commit message, this test passes and I can build perl successfully.

I'm happy to provide more information on request or run any commands
that might offer useful insight.

Thanks for the report. If I'm counting right that test looks like​:

# close during print

fresh_io;
$SIG{ALRM} = sub { $sigst = close($out) ? "ok" : "nok" };
$buf = "a" x 1_000_000 . "\n"; # bigger than any pipe buffer hopefully
select $out; $| = 1; select STDOUT;
alarm(1);
$st = print $out $buf;
alarm(0);
is($sigst, 'nok', 'print/close​: sig handler close status');
ok(!$st, 'print/close​: print status');
ok(!close($out), 'print/close​: close status');

I'm guessing it's the print statement and I'm further guessing that we
crossed the threshold described here​:

http​://lists.freebsd.org/pipermail/freebsd-arch/2007-September/006790.html

so that, since we now write 8192 bytes in one go, the pipe
implementation attempts a direct write rather than a buffered write,
and the direct write is not interruptible by the alarm. But I know
nothing about BSD internals, so that's a speculation based on an
assumption derived from a hunch. I'd be grateful to anyone who can
confirm my guesses or come up with better ones.

But it must be something related to writing more at one time. So the
question becomes, what should Perl do about it? The path of least
resistance is to simply revert this change, at least for 5.14, and it
may come to that.

One alternative is to add something to hints/freebsd.sh so FreeBSD
gets the old default buffer size, though that would give you smaller
buffers for all input and output streams, not just output to pipes,
where the trouble seems to be.

Another alternative is to allocate a different buffer size for special
files than for regular files, which I guess would involve doing an
fstat() right after opening an output stream to see what kind of
widget we're writing to.

Or if we're going to do an fstat(), perhaps grab st_blksize and use
that as the buffer size, at least for special files (or when S_ISFIFO
is true). But that would only work if st_blksize for a pipe is less
than 8192 on FreeBSD. We'd also probably have to come up with minimum
and maximum guard values in case we get an st_blksize that isn't sane.

Just thinking out loud for now.

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2011

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2011

From @Leont

On Thu, Mar 10, 2011 at 9​:19 PM, Craig A. Berry <craig.a.berry@​gmail.com> wrote​:

But it must be something related to writing more at one time.  So the
question becomes, what should Perl do about it?  The path of least
resistance is to simply revert this change, at least for 5.14, and it
may come to that.

That would seem a bit drastic

One alternative is to add something to hints/freebsd.sh so FreeBSD
gets the old default buffer size, though that would give you smaller
buffers for all input and output streams, not just output to pipes,
where the trouble seems to be.

Sounds like a reasonable stopgap solution to me. We should actively
check on other platforms too though in that case.

Another alternative is to allocate a different buffer size for special
files than for regular files, which I guess would involve doing an
fstat() right after opening an output stream to see what kind of
widget we're writing to.

Or if we're going to do an fstat(), perhaps grab st_blksize and use
that as the buffer size, at least for special files (or when S_ISFIFO
is true).  But that would only work if st_blksize for a pipe is less
than 8192 on FreeBSD.  We'd also probably have to come up with minimum
and maximum guard values in case we get an st_blksize that isn't sane.

IMO, that whole part of PerlIO should be reworked. It should be a
property of the handle, not a constant. That's for 5.16 though.

Leon

@p5pRT
Copy link
Author

p5pRT commented Mar 11, 2011

From @iabyn

On Thu, Mar 10, 2011 at 10​:08​:19PM +0100, Leon Timmermans wrote​:

On Thu, Mar 10, 2011 at 9​:19 PM, Craig A. Berry <craig.a.berry@​gmail.com> wrote​:

But it must be something related to writing more at one time.  So the
question becomes, what should Perl do about it?  The path of least
resistance is to simply revert this change, at least for 5.14, and it
may come to that.

That would seem a bit drastic

One alternative is to add something to hints/freebsd.sh so FreeBSD
gets the old default buffer size, though that would give you smaller
buffers for all input and output streams, not just output to pipes,
where the trouble seems to be.

Sounds like a reasonable stopgap solution to me. We should actively
check on other platforms too though in that case.

Note that the hanging test is designed to test the stability of PerlIO
when IO operations (such as close) are performed by an interrupt handler
within an interrupted system call.

If the particular OS's write system call isn't interruptable, then I think
the best thing is to just skip these tests for BSD (we already skip for
Win32, VMS etc).

--
You're only as old as you look.

@p5pRT
Copy link
Author

p5pRT commented Mar 11, 2011

From @iabyn

On Fri, Mar 11, 2011 at 02​:05​:10PM +0000, Dave Mitchell wrote​:

Note that the hanging test is designed to test the stability of PerlIO
when IO operations (such as close) are performed by an interrupt handler
within an interrupted system call.

If the particular OS's write system call isn't interruptable, then I think
the best thing is to just skip these tests for BSD (we already skip for
Win32, VMS etc).

PS - this looks similar to [perl #84688] io/eintr.t test hangs indefinitely

--
Please note that ash-trays are provided for the use of smokers,
whereas the floor is provided for the use of all patrons.
  -- Bill Royston

@p5pRT
Copy link
Author

p5pRT commented Mar 11, 2011

From @tomhukins

On Fri, Mar 11, 2011 at 06​:51​:25AM -0800, Dave Mitchell via RT wrote​:

PS - this looks similar to [perl #84688] io/eintr.t test hangs indefinitely

It does. I apologise for not searching the existing bug reports
before opening a new one.

Tom

@p5pRT
Copy link
Author

p5pRT commented Mar 12, 2011

From @craigberry

On Fri, Mar 11, 2011 at 8​:05 AM, Dave Mitchell <davem@​iabyn.com> wrote​:

Note that the hanging test is designed to test the stability of PerlIO
when IO operations (such as close) are performed by an interrupt handler
within an interrupted system call.

If the particular OS's write system call isn't interruptable, then I think
the best thing is to just skip these tests for BSD (we already skip for
Win32, VMS etc).

I went ahead and added a skip for FreeBSD so at least the test suite won't hang.

http​://perl5.git.perl.org/perl.git/commitdiff/c81114d2b6e9ca2fa098dbdac89edfaca24540f9

I have had a glance at the FreeBSD pipe implementation here​:

http​://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/sys_pipe.c

and it's very foreign territory for me so I'm not really in a position
to suggest what FreeBSD ought to be doing differently, if anything.
But the more I think about it the less I think it's Perl's job to
parcel out its writes in smaller pieces so a particular pipe
implementation can handle them.

@p5pRT
Copy link
Author

p5pRT commented Mar 12, 2011

@cpansprout - Status changed from 'open' to 'resolved'

@p5pRT
Copy link
Author

p5pRT commented Mar 18, 2011

From @doughera88

On Fri, 11 Mar 2011, Craig A. Berry wrote​:

On Fri, Mar 11, 2011 at 8​:05 AM, Dave Mitchell <davem@​iabyn.com> wrote​:

Note that the hanging test is designed to test the stability of PerlIO
when IO operations (such as close) are performed by an interrupt handler
within an interrupted system call.

If the particular OS's write system call isn't interruptable, then I think
the best thing is to just skip these tests for BSD (we already skip for
Win32, VMS etc).

I went ahead and added a skip for FreeBSD so at least the test suite won't hang.

I observed the same "hang" on Solaris 8/SPARC. I'll investigate Solaris
11 (and maybe 10) to see if I can guess how broad a "skip" to put in
place.

--
  Andy Dougherty doughera@​lafayette.edu

@p5pRT
Copy link
Author

p5pRT commented Mar 22, 2011

From @doughera88

On Fri, 18 Mar 2011, Andy Dougherty wrote​:

On Fri, 11 Mar 2011, Craig A. Berry wrote​:

On Fri, Mar 11, 2011 at 8​:05 AM, Dave Mitchell <davem@​iabyn.com> wrote​:

Note that the hanging test is designed to test the stability of PerlIO
when IO operations (such as close) are performed by an interrupt handler
within an interrupted system call.

If the particular OS's write system call isn't interruptable, then I think
the best thing is to just skip these tests for BSD (we already skip for
Win32, VMS etc).

I went ahead and added a skip for FreeBSD so at least the test suite won't hang.

I observed the same "hang" on Solaris 8/SPARC. I'll investigate Solaris
11 (and maybe 10) to see if I can guess how broad a "skip" to put in
place.

Solaris 10 and 11 are fine. I don't have Solaris 9 around for testing. At
a minimum, this patch is appropriate. Unless there's an objection
objections, I'll go ahead and apply this.

Inline Patch
diff --git a/t/io/eintr.t b/t/io/eintr.t
index dc93660..04952b6 100644
--- a/t/io/eintr.t
+++ b/t/io/eintr.t
@@ -45,7 +45,8 @@ if (exists $ENV{PERLIO} && $ENV{PERLIO} =~ /stdio/  ) {
 # On FreeBSD, writes to pipes of 8192 bytes or more use a mechanism
 # that is not interruptible (see perl #85842 and #84688).
 
-if ($^O eq 'VMS' || $^O eq 'MSWin32' || $^O eq 'cygwin' || $^O eq 'freebsd') {
+if ($^O eq 'VMS' || $^O eq 'MSWin32' || $^O eq 'cygwin' || $^O eq 'freebsd' || 
+     ($^O eq 'solaris' && $Config{osvers} eq '2.8') ) {
 	skip_all('various portability issues');
 	exit 0;
 }

-- 

  Andy Dougherty doughera@​lafayette.edu

@p5pRT
Copy link
Author

p5pRT commented Mar 22, 2011

@doughera88 - Status changed from 'resolved' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Mar 22, 2011

From @ikegami

On Tue, Mar 22, 2011 at 9​:31 AM, Andy Dougherty <doughera@​lafayette.edu>wrote​:

diff --git a/t/io/eintr.t b/t/io/eintr.t
index dc93660..04952b6 100644
--- a/t/io/eintr.t
+++ b/t/io/eintr.t
@​@​ -45,7 +45,8 @​@​ if (exists $ENV{PERLIO} && $ENV{PERLIO} =~ /stdio/ ) {
# On FreeBSD, writes to pipes of 8192 bytes or more use a mechanism
# that is not interruptible (see perl #85842 and #84688).

-if ($^O eq 'VMS' || $^O eq 'MSWin32' || $^O eq 'cygwin' || $^O eq
'freebsd') {
+if ($^O eq 'VMS' || $^O eq 'MSWin32' || $^O eq 'cygwin' || $^O eq
'freebsd' ||
+ ($^O eq 'solaris' && $Config{osvers} eq '2.8') ) {
skip_all('various portability issues');
exit 0;
}

Should Solaris be added to the comment?

@p5pRT
Copy link
Author

p5pRT commented Mar 22, 2011

From @doughera88

On Tue, 22 Mar 2011, Eric Brine wrote​:

On Tue, Mar 22, 2011 at 9​:31 AM, Andy Dougherty <doughera@​lafayette.edu>wrote​:

diff --git a/t/io/eintr.t b/t/io/eintr.t
index dc93660..04952b6 100644
--- a/t/io/eintr.t
+++ b/t/io/eintr.t
@​@​ -45,7 +45,8 @​@​ if (exists $ENV{PERLIO} && $ENV{PERLIO} =~ /stdio/ ) {
# On FreeBSD, writes to pipes of 8192 bytes or more use a mechanism
# that is not interruptible (see perl #85842 and #84688).

-if ($^O eq 'VMS' || $^O eq 'MSWin32' || $^O eq 'cygwin' || $^O eq
'freebsd') {
+if ($^O eq 'VMS' || $^O eq 'MSWin32' || $^O eq 'cygwin' || $^O eq
'freebsd' ||
+ ($^O eq 'solaris' && $Config{osvers} eq '2.8') ) {
skip_all('various portability issues');
exit 0;
}

Should Solaris be added to the comment?

I suppose so, but I haven't actually tested whether it's the same problem
on Solaris 8 as BSD or whether it's something different. The problem also
is not present on Solaris 10 or 11, so it's only relevant for some very
old systems. Given that I hadn't researched it very well, almost nobody
will case, and all the rest of the detail is in the RT tickets, I hadn't
worried about it much either way.

Still, I guess I'll add something like
  "# Also hangs on Solaris 8 (but not 10 or 11)."

Thanks for the gentle reminder.

--
  Andy Dougherty doughera@​lafayette.edu

@p5pRT
Copy link
Author

p5pRT commented Mar 23, 2011

From @cpansprout

On Tue Mar 22 06​:31​:49 2011, doughera wrote​:

diff --git a/t/io/eintr.t b/t/io/eintr.t
index dc93660..04952b6 100644
--- a/t/io/eintr.t
+++ b/t/io/eintr.t
@​@​ -45,7 +45,8 @​@​ if (exists $ENV{PERLIO} && $ENV{PERLIO} =~ /stdio/
) {
# On FreeBSD, writes to pipes of 8192 bytes or more use a mechanism
# that is not interruptible (see perl #85842 and #84688).

-if ($^O eq 'VMS' || $^O eq 'MSWin32' || $^O eq 'cygwin' || $^O eq
'freebsd') {
+if ($^O eq 'VMS' || $^O eq 'MSWin32' || $^O eq 'cygwin' || $^O eq
'freebsd' ||
+ ($^O eq 'solaris' && $Config{osvers} eq '2.8') ) {
skip_all('various portability issues');
exit 0;
}

This this has now been applied as 384f75d, I’m marking this as resolved
again.

@p5pRT
Copy link
Author

p5pRT commented Mar 23, 2011

@cpansprout - Status changed from 'open' to 'resolved'

@p5pRT p5pRT closed this as completed Mar 23, 2011
@p5pRT
Copy link
Author

p5pRT commented Apr 28, 2011

From rwstauner@cpan.org

I hit the same problem trying to install 5.14.0-RC1 with perlbrew on
some *OLD* Linux distros...

I installed 5.12.3 with no trouble, though I believe this io/eintr.t
file came in 5.13.

I wasn't sure where I could find minimum system requirements,
so I apologize if I shouldn't have bothered with this,
but I also wasn't sure where the breakdown was so I thought perhaps
someone would be interested.
It's probably my ancient kernels​:

Linux 2.6.5-1.358 #1 Sat May 8 09​:04​:50 EDT 2004 i686 i686 i386
GNU/Linux
Linux 2.6.10-1.771_FC2 #1 Mon Mar 28 00​:50​:14 EST 2005 i686 i686 i386
GNU/Linux

gcc (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7) (2003)
glibc-2.3.3
Fedora Core release 2 (Tettnang)

I skipped the test and everything seems ok (no pun intended).

Let me know if you'd like any more information,
or please ignore this if this system is too old...
I can't imagine anybody cares.

The next oldest machine I could try it on was​:

Linux 2.6.12-1.1381_FC3smp #1 SMP Fri Oct 21 04​:03​:26 EDT 2005 i686 i686
i386 GNU/Linux
Fedora Core release 3 (Heidelberg)
glibc-2.3.6
gcc (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2) (2004)

and I had no problems.

@p5pRT
Copy link
Author

p5pRT commented Apr 28, 2011

From [Unknown Contact. See original ticket]

I hit the same problem trying to install 5.14.0-RC1 with perlbrew on
some *OLD* Linux distros...

I installed 5.12.3 with no trouble, though I believe this io/eintr.t
file came in 5.13.

I wasn't sure where I could find minimum system requirements,
so I apologize if I shouldn't have bothered with this,
but I also wasn't sure where the breakdown was so I thought perhaps
someone would be interested.
It's probably my ancient kernels​:

Linux 2.6.5-1.358 #1 Sat May 8 09​:04​:50 EDT 2004 i686 i686 i386
GNU/Linux
Linux 2.6.10-1.771_FC2 #1 Mon Mar 28 00​:50​:14 EST 2005 i686 i686 i386
GNU/Linux

gcc (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7) (2003)
glibc-2.3.3
Fedora Core release 2 (Tettnang)

I skipped the test and everything seems ok (no pun intended).

Let me know if you'd like any more information,
or please ignore this if this system is too old...
I can't imagine anybody cares.

The next oldest machine I could try it on was​:

Linux 2.6.12-1.1381_FC3smp #1 SMP Fri Oct 21 04​:03​:26 EDT 2005 i686 i686
i386 GNU/Linux
Fedora Core release 3 (Heidelberg)
glibc-2.3.6
gcc (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2) (2004)

and I had no problems.

@p5pRT
Copy link
Author

p5pRT commented Apr 28, 2011

From @toddr

This hang is repeatable on CentOS/RedHat 4 32/64 with all packages up to date. The login now
says that support for RedHat 4 ends on Feb 29 2012 so this is still potentially used by many
people.

[root@​rpmb-centos-4-32bit perl-5.14.0-RC2]# uname -a
Linux centos-4-32bit 2.6.9-100.EL.plus.c4smp #1 SMP Fri Feb 18 03​:46​:19 EST 2011 i686 i686
i386 GNU/Linux

@p5pRT
Copy link
Author

p5pRT commented Apr 28, 2011

From @toddr

Nicholas requested an strace. I believe that below are the relevant lines.

write(1, "ok 5 - read/die​: close status\n", 30ok 5 - read/die​: close status
) = 30
close(4) = 0
pipe([3, 4]) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fbffff530) = -1 EINVAL (Invalid argument)
lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fbffff530) = -1 EINVAL (Invalid argument)
lseek(4, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
rt_sigaction(SIGALRM, {0x47c600, [], SA_RESTORER, 0x2a95c77300}, {0x47c600, [],
SA_RESTORER, 0x2a95c77300}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
mmap(NULL, 1003520, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2a98ccd000
mmap(NULL, 1003520, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2a98dc2000
alarm(1) = 0
write(4, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 8192) = 4096
--- SIGALRM (Alarm clock) @​ 0 (0) ---
rt_sigreturn(0xe) = 4096
write(4, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 4096

Note the last line appears to be incomplete.

@p5pRT
Copy link
Author

p5pRT commented Apr 28, 2011

From @toddr

[root@​rpmb-centos-4-32bit perl-5.14.0-RC2]# uname -a
Linux centos-4-32bit 2.6.9-100.EL.plus.c4smp #1 SMP Fri Feb 18
03​:46​:19 EST 2011 i686 i686
i386 GNU/Linux

CentOS 4 is GCC 3.4.6-11

@p5pRT
Copy link
Author

p5pRT commented May 2, 2011

From rwstauner@cpan.org

confirmed problem exists on Debian 3.1

Linux 2.4.27-hm64smp #1 SMP Wed Mar 14 22​:34​:19 CDT 2007 i686 GNU/Linux

gcc (GCC) 3.3.5 (Debian 1​:3.3.5-8)

I sent a signal to the test script from another terminal to get the
process to continue.

@p5pRT
Copy link
Author

p5pRT commented May 2, 2011

From @toddr

On May 2, 2011, at 4​:32 PM, Randy Stauner via RT wrote​:

confirmed problem exists on Debian 3.1

Linux 2.4.27-hm64smp #1 SMP Wed Mar 14 22​:34​:19 CDT 2007 i686 GNU/Linux

gcc (GCC) 3.3.5 (Debian 1​:3.3.5-8)

I sent a signal to the test script from another terminal to get the
process to continue.

Is this a release blocker? http​://bit.ly/blocks-514

@p5pRT
Copy link
Author

p5pRT commented May 3, 2011

From @iabyn

On Mon, May 02, 2011 at 06​:43​:24PM -0500, Todd Rinaldo wrote​:

On May 2, 2011, at 4​:32 PM, Randy Stauner via RT wrote​:

confirmed problem exists on Debian 3.1

Linux 2.4.27-hm64smp #1 SMP Wed Mar 14 22​:34​:19 CDT 2007 i686 GNU/Linux

gcc (GCC) 3.3.5 (Debian 1​:3.3.5-8)

I sent a signal to the test script from another terminal to get the
process to continue.

Is this a release blocker? http​://bit.ly/blocks-514

Well its a bug in the test script rather than in perl.
It tests what happens when a signal handler does Bad Things (like doing
IO) when called from within an interrupted IO system call. The problem is
that a large number of platforms aren't interrruptable, so the test hangs.
We already skip win32, freebsd etc., but it looks like either older linux
has the same problem, or there's a race condition somewhere in the test.

Jesse, I propose for 5.14.0-RC2, that I put in a general skip on
release version number in that test file (like we have for
t/re/reg_eval_scope.t) So the test skips on 5.14.* but not 5.15.*

Let me know if that's ok.

--
"You're so sadly neglected, and often ignored.
A poor second to Belgium, When going abroad."
  -- Monty Python, "Finland"

@p5pRT
Copy link
Author

p5pRT commented May 3, 2011

From @obra

On Tue, May 03, 2011 at 11​:59​:26AM +0100, Dave Mitchell wrote​:

On Mon, May 02, 2011 at 06​:43​:24PM -0500, Todd Rinaldo wrote​:

On May 2, 2011, at 4​:32 PM, Randy Stauner via RT wrote​:

confirmed problem exists on Debian 3.1

Linux 2.4.27-hm64smp #1 SMP Wed Mar 14 22​:34​:19 CDT 2007 i686 GNU/Linux

gcc (GCC) 3.3.5 (Debian 1​:3.3.5-8)

I sent a signal to the test script from another terminal to get the
process to continue.

Is this a release blocker? http​://bit.ly/blocks-514

Well its a bug in the test script rather than in perl.
It tests what happens when a signal handler does Bad Things (like doing
IO) when called from within an interrupted IO system call. The problem is
that a large number of platforms aren't interrruptable, so the test hangs.
We already skip win32, freebsd etc., but it looks like either older linux
has the same problem, or there's a race condition somewhere in the test.

Jesse, I propose for 5.14.0-RC2, that I put in a general skip on
release version number in that test file (like we have for
t/re/reg_eval_scope.t) So the test skips on 5.14.* but not 5.15.*

Let me know if that's ok.

Does it make sense for us to skip on release versions or only on 5.14?
(Whatever your answer, please commit such a change.)

It'd be nice if, in the glorious future, we has characteristic-based
skips rather than osname based skips.

-j

--
"You're so sadly neglected, and often ignored.
A poor second to Belgium, When going abroad."
-- Monty Python, "Finland"

--

@p5pRT
Copy link
Author

p5pRT commented May 3, 2011

From @iabyn

On Tue, May 03, 2011 at 10​:35​:28AM -0400, Jesse Vincent wrote​:

Does it make sense for us to skip on release versions or only on 5.14?
(Whatever your answer, please commit such a change.)

I've gone for all production releases, so I could just cut+paste
the (tested and working) skip code from t/re/reg_eval_scope.t.
We can always revisit this post 5.14.

It'd be nice if, in the glorious future, we has characteristic-based
skips rather than osname based skips.

Along with the rainbow-farting unicorns ;-)

--
It's not that I'm afraid to die, I just don't want to be there when it
happens.
  -- Woody Allen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant