Closed p5pRT closed 13 years ago
p5pRT
commented
13 years ago My FreeBSD blead smoker has been hanging at test 6 in t/io/eintr.t for the past few days. git bisect tracked it down to commit df375c6d048b938ecdeaecc7b264a7f1a190120a ([perl #8611] eintr.t: skip based on capability rather than OS)
p5pRT
commented
13 years ago That commit changed from a hard-coded list of OSes to skip to a probe to see if things are interruptable.
Unless there is good reason for the change\, I think we should just revert.
Dave M -- as it was your commit\, I'm assigning this ticket to you to resolve the FreeBSD issue or please revert the commit.
Thanks\,
David G (RMOTM)
p5pRT
commented
13 years ago The RT System itself - Status changed from 'new' to 'open'
p5pRT
commented
13 years ago On Tue\, Jun 14\, 2011 at 08:43:08AM -0700\, brian greenfield wrote:
----------------------------------------------------------------- [Please describe your issue here]
My FreeBSD blead smoker has been hanging at test 6 in t/io/eintr.t for the past few days. git bisect tracked it down to commit df375c6d048b938ecdeaecc7b264a7f1a190120a ([perl #8611] eintr.t: skip based on capability rather than OS)
I see this. The relevant bits of kdump seem to be:
34054 perl GIO fd 1 wrote 30 bytes "ok 5 - read/die: close status " 34054 perl RET write 30/0x1e 34054 perl CALL close(0x4) 34054 perl RET close 0 34054 perl CALL pipe 34054 perl RET pipe 3 34054 perl CALL ioctl(0x3\,TIOCGETA\,0x7fffffffe750) 34054 perl RET ioctl -1 errno 25 Inappropriate ioctl for device 34054 perl CALL lseek(0x3\,0\,SEEK_CUR) 34054 perl RET lseek -1 errno 29 Illegal seek 34054 perl CALL ioctl(0x4\,TIOCGETA\,0x7fffffffe750) 34054 perl RET ioctl -1 errno 25 Inappropriate ioctl for device 34054 perl CALL lseek(0x4\,0\,SEEK_CUR) 34054 perl RET lseek -1 errno 29 Illegal seek 34054 perl CALL fcntl(0x3\,F_SETFD\,FD_CLOEXEC) 34054 perl RET fcntl 0 34054 perl CALL fcntl(0x4\,F_SETFD\,FD_CLOEXEC) 34054 perl RET fcntl 0 34054 perl CALL sigprocmask(SIG_BLOCK\,0x7fffffffe8a0\,0x7fffffffe910) 34054 perl RET sigprocmask 0 34054 perl CALL sigaction(SIGALRM\,0x7fffffffe890\,0x7fffffffe870) 34054 perl RET sigaction 0 34054 perl CALL sigprocmask(SIG_SETMASK\,0x7fffffffe730\,0) 34054 perl RET sigprocmask 0 34054 perl CALL mmap(0\,0x100000\,PROT_READ|PROT_WRITE\,MAP_PRIVATE|MAP_ANON\, 0xffffffff\,0) 34054 perl RET mmap 16777216/0x801000000 34054 perl CALL mmap(0\,0x100000\,PROT_READ|PROT_WRITE\,MAP_PRIVATE|MAP_ANON\, 0xffffffff\,0) 34054 perl RET mmap 17825792/0x801100000 34054 perl CALL setitimer(0\,0x7fffffffe9d0\,0x7fffffffe9b0) 34054 perl RET setitimer 0 34054 perl CALL write(0x4\,0x800f40000\,0x2000) 34054 perl GIO fd 4 wrote 4096 bytes "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
...
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" 34054 perl RET write 8192/0x2000 34054 perl PSIG SIGALRM caught handler=0x4b8740 mask=0x0 code=0x0 34054 perl CALL sigreturn(0x7fffffffe260) 34054 perl RET sigreturn JUSTRETURN 34054 perl CALL write(0x4\,0x800f40000\,0x2000)
ie a write to a pipe is restarted.
Except\, how come it has reached test 5 before a write restarts? Shouldn't the earlier probe bail out?
Nicholas Clark
p5pRT
commented
13 years ago On Tue\, Jun 14\, 2011 at 4:10 PM\, Nicholas Clark \nick@​ccl4\.org wrote:
On Tue\, Jun 14\, 2011 at 08:43:08AM -0700\, brian greenfield wrote:
----------------------------------------------------------------- [Please describe your issue here]
My FreeBSD blead smoker has been hanging at test 6 in t/io/eintr.t for the past few days. git bisect tracked it down to commit df375c6d048b938ecdeaecc7b264a7f1a190120a ([perl #8611] eintr.t: skip based on capability rather than OS)
ie a write to a pipe is restarted.
Except\, how come it has reached test 5 before a write restarts? Shouldn't the earlier probe bail out?
The comments in the test script indicate:
# On FreeBSD\, writes to pipes of 8192 bytes or more use a mechanism # that is not interruptible (see perl #85842 and #84688).
I think the probe just opens the pipe and doesn't actually move data through it\, especially not a chunk of data large enough to trigger the FreeBSD-specific pipe problem.
p5pRT
commented
13 years ago On Tue\, Jun 14\, 2011 at 10:10:36PM -0500\, Craig A. Berry wrote:
On Tue\, Jun 14\, 2011 at 4:10 PM\, Nicholas Clark \nick@​ccl4\.org wrote:
On Tue\, Jun 14\, 2011 at 08:43:08AM -0700\, brian greenfield wrote:
----------------------------------------------------------------- [Please describe your issue here]
My FreeBSD blead smoker has been hanging at test 6 in t/io/eintr.t for the past few days. git bisect tracked it down to commit df375c6d048b938ecdeaecc7b264a7f1a190120a ([perl #8611] eintr.t: skip based on capability rather than OS)
ie a write to a pipe is restarted.
Except\, how come it has reached test 5 before a write restarts? Shouldn't the earlier probe bail out?
The comments in the test script indicate:
# On FreeBSD\, writes to pipes of 8192 bytes or more use a mechanism # that is not interruptible (see perl #85842 and #84688).
I think the probe just opens the pipe and doesn't actually move data through it\, especially not a chunk of data large enough to trigger the FreeBSD-specific pipe problem.
Now fixed (hopefully) by the following:
commit 6e59d93aee950461947904b4f24a7f52c6c85f58 Author: David Mitchell \davem@​iabyn\.com AuthorDate: Wed Jun 15 15:07:57 2011 +0100 Commit: David Mitchell \davem@​iabyn\.com CommitDate: Wed Jun 15 15:11:27 2011 +0100
[perl #92828] eintr.t hangs on FreeBSD
My commit df375c6d048b938ecdeaecc7b264a7f1a190120a attempted to
convert t/io/eintr.t from OS-based skipping to capability-based skipping\,
but it only tested whether reads from pipes are interruptible.
Some OSes (like FreeBSD) only hang on write; so probe for that too.
Affected files ...
M t/io/eintr.t
-- "You may not work around any technical limitations in the software" -- Windows Vista license
p5pRT
commented
13 years ago @iabyn - Status changed from 'open' to 'resolved'
p5pRT
commented
13 years ago On Wed\, Jun 15\, 2011 at 03:12:29PM +0100\, Dave Mitchell wrote:
On Tue\, Jun 14\, 2011 at 10:10:36PM -0500\, Craig A. Berry wrote:
On Tue\, Jun 14\, 2011 at 4:10 PM\, Nicholas Clark \nick@​ccl4\.org wrote:
On Tue\, Jun 14\, 2011 at 08:43:08AM -0700\, brian greenfield wrote:
----------------------------------------------------------------- [Please describe your issue here]
My FreeBSD blead smoker has been hanging at test 6 in t/io/eintr.t for the past few days. git bisect tracked it down to commit df375c6d048b938ecdeaecc7b264a7f1a190120a ([perl #8611] eintr.t: skip based on capability rather than OS)
ie a write to a pipe is restarted.
Except\, how come it has reached test 5 before a write restarts? Shouldn't the earlier probe bail out?
The comments in the test script indicate:
# On FreeBSD\, writes to pipes of 8192 bytes or more use a mechanism # that is not interruptible (see perl #85842 and #84688).
I think the probe just opens the pipe and doesn't actually move data through it\, especially not a chunk of data large enough to trigger the FreeBSD-specific pipe problem.
Now fixed (hopefully) by the following:
commit 6e59d93aee950461947904b4f24a7f52c6c85f58
This test still hangs for me in the same way as before. The kdump output looks much like the one Nicholas posted earlier.
Tom
p5pRT
commented
13 years ago On Wed\, Jun 15\, 2011 at 03:59:25PM +0100\, Tom Hukins wrote:
On Wed\, Jun 15\, 2011 at 03:12:29PM +0100\, Dave Mitchell wrote:
On Tue\, Jun 14\, 2011 at 10:10:36PM -0500\, Craig A. Berry wrote:
On Tue\, Jun 14\, 2011 at 4:10 PM\, Nicholas Clark \nick@​ccl4\.org wrote:
On Tue\, Jun 14\, 2011 at 08:43:08AM -0700\, brian greenfield wrote:
----------------------------------------------------------------- [Please describe your issue here]
My FreeBSD blead smoker has been hanging at test 6 in t/io/eintr.t for the past few days. git bisect tracked it down to commit df375c6d048b938ecdeaecc7b264a7f1a190120a ([perl #8611] eintr.t: skip based on capability rather than OS)
ie a write to a pipe is restarted.
Except\, how come it has reached test 5 before a write restarts? Shouldn't the earlier probe bail out?
The comments in the test script indicate:
# On FreeBSD\, writes to pipes of 8192 bytes or more use a mechanism # that is not interruptible (see perl #85842 and #84688).
I think the probe just opens the pipe and doesn't actually move data through it\, especially not a chunk of data large enough to trigger the FreeBSD-specific pipe problem.
Now fixed (hopefully) by the following:
commit 6e59d93aee950461947904b4f24a7f52c6c85f58
This test still hangs for me in the same way as before. The kdump output looks much like the one Nicholas posted earlier.
Sadly\, me too\, on FreeBSD 7.2:
Summary of my perl5 (revision 5 version 15 subversion 0) configuration: Commit id: 6e59d93aee950461947904b4f24a7f52c6c85f58 Platform: osname=freebsd\, osvers=7.2-release\, archname=amd64-freebsd-thread-multi uname='freebsd spectre.mongueurs.net 7.2-release freebsd 7.2-release #0: fri may 1 07:18:07 utc 2009 root@driscoll.cse.buffalo.edu:usrobjusrsrcsysgeneric amd64 ' config_args='-Dgccansipedantic -Accflags=-ansi -pedantic -Dusedevel=y -Dcc=ccache gcc -Dld=gcc -Ubincompat5005 -Uinstallusrbinperl -Dcf_email=nick@ccl4.org -Dperladmin=nick@ccl4.org -Dinc_version_list= -Dinc_version_list_init=0 -Doptimize=-g -Dusethreads -Duse64bitint -Accflags=-DNO_MATHOMS -Uusemymalloc -Duseperlio -Dprefix=~/Sandpit/snap5.9.x- -Dinstallman1dir=none -Dinstallman3dir=none -Uuserelocatableinc -de' hint=recommended\, useposix=true\, d_sigaction=define useithreads=define\, usemultiplicity=define useperlio=define\, d_sfio=undef\, uselargefiles=define\, usesocks=undef use64bitint=define\, use64bitall=define\, uselongdouble=undef usemymalloc=n\, bincompat5005=undef Compiler: cc='ccache gcc'\, ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -ansi -pedantic -DNO_MATHOMS -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'\, optimize='-g'\, cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -ansi -pedantic -DNO_MATHOMS -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='gcc'\, ldflags ='-pthread -Wl\,-E -fstack-protector -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lgdbm -lm -lcrypt perllibs=-lm -lcrypt libc=\, so=so\, useshrplib=false\, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags=' ' cccdlflags='-DPIC -fPIC'\, lddlflags='-shared -L/usr/local/lib -fstack-protector'
Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY NO_MATHOMS PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_USE_DEVEL USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API Built under freebsd Compiled at Jun 15 2011 16:26:46 @INC: lib /home/nicholas/Sandpit/snap5.9.x-/lib/perl5/site_perl/5.15.0/amd64-freebsd-thread-multi /home/nicholas/Sandpit/snap5.9.x-/lib/perl5/site_perl/5.15.0 /home/nicholas/Sandpit/snap5.9.x-/lib/perl5/5.15.0/amd64-freebsd-thread-multi /home/nicholas/Sandpit/snap5.9.x-/lib/perl5/5.15.0 .
Nicholas Clark
p5pRT
commented
13 years ago On Wed\, Jun 15\, 2011 at 04:06:39PM +0100\, Nicholas Clark wrote:
On Wed\, Jun 15\, 2011 at 03:59:25PM +0100\, Tom Hukins wrote:
On Wed\, Jun 15\, 2011 at 03:12:29PM +0100\, Dave Mitchell wrote:
Now fixed (hopefully) by the following:
commit 6e59d93aee950461947904b4f24a7f52c6c85f58
This test still hangs for me in the same way as before. The kdump output looks much like the one Nicholas posted earlier.
Sadly\, me too\, on FreeBSD 7.2
Ok\, I've given up for now and reverted my last two eintr.t changes
-- "You're so sadly neglected\, and often ignored. A poor second to Belgium\, When going abroad." -- Monty Python\, "Finland"
Migrated from rt.perl.org#92828 (status was 'resolved')
Searchable as RT92828$