[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Diffutils-devel] [platform-testers] new snapshot available: diffuti
From: |
Jim Meyering |
Subject: |
Re: [Diffutils-devel] [platform-testers] new snapshot available: diffutils-3.5.25-c881 |
Date: |
Tue, 9 May 2017 13:12:04 -0700 |
On Mon, May 8, 2017 at 7:59 PM, Assaf Gordon <address@hidden> wrote:
> Hello,
>
>> On May 6, 2017, at 18:48, Jim Meyering <address@hidden> wrote:
>> http://meyering.net/diff/diffutils-3.5.25-c881.tar.xz
>
> Few test failures:
>
> On AIX 7:
> ===
>
> FAIL: test-c-stack.sh
> =====================
>
> ./test-c-stack.sh[7]: 27525196 Illegal instruction(coredump)
> FAIL test-c-stack.sh (exit status: 1)
>
> FAIL: test-c-stack2.sh
> ======================
>
> FAIL test-c-stack2.sh (exit status: 1)
Those are gnulib's tests to exercise detection of stack overflow.
That they fail on AIX need not delay diffutils release.
> ===
>
> On NetBSD 7.0 and Minix: 'new-file' fails.
> Log attached, also available here:
> https://pretest.housegordon.org/g/4669/logs/tests-suite-summary.log
This means that those hosts do not work as expected when we tell diff
to read from a closed standard input (or that the shell fails to do
what "<&-" is specified to do). This is the behavior we expect (exit
with status 2):
$ touch a && diff --unidirectional-new-file a - <&- > out
diff: -: Bad file descriptor
[Exit 2]
I've just adjusted that sub-test to also require that "out" be empty.
If someone wants to investigate, that would be nice:
- if it's a shell problem, we may want to work around it
- if it's a kernel or libc issue, it'd be good to know
Consider running these commands with different shells:
$ echo |cat - <&-
cat: -: Bad file descriptor
cat: closing standard input: Bad file descriptor
[Exit 1]
$ echo |head - <&-
head: error reading 'standard input': Bad file descriptor
head: -: Bad file descriptor
[Exit 1]
$ echo | grep - <&-
grep: (standard input): Bad file descriptor
[Exit 2]
Either way, this need not hold up the release.
> Otherwise, no failures on the following:
> CentOS 6.5 (x86_64)
> CentOS 7.0.1406 (x86_64)
> Darwin 14.5.0 (x86_64)
> Darwin 15.6.0 (x86_64)
> Darwin 15.6.0 (x86_64)
> Darwin 15.6.0 (x86_64)
> Debian 7.6 (x86_64)
> Debian 8.1 (x86_64)
> Fedora 20 (ppc64)
> Fedora 21 (x86_64)
> Fedora 22 (x86_64)
> Fedora 23 (x86_64)
> Fedora 24 (x86_64)
> Fedora 25 (x86_64)
> FreeBSD 10.1-RELEASE (amd64)
> FreeBSD 10.3-RELEASE (amd64)
> FreeBSD 11.0-RELEASE-p1 (amd64)
> FreeBSD 9.3-RELEASE (amd64)
> GNU 0.7 (i686-AT386)
> OpenBSD 5.7 (amd64)
> OpenBSD 5.8 (amd64)
> OpenBSD 6.0 (amd64)
> OpenBSD 6.1 (amd64)
> OpenIndiana SunOS 5.11 (i86pc)
> Oracle SunOS 5.10 (i86pc)
> Oracle SunOS 5.10 (sun4v)
> Oracle SunOS 5.11 (i86pc)
> Oracle SunOS 5.11 (sun4u)
> SUSE LINUX 42.1 (x86_64)
> Trisquel 6.0.1 (x86_64)
> Trisquel 7.0 (x86_64)
> Ubuntu 14.04 (aarch64)
> Ubuntu 14.04 (x86_64)
> Ubuntu 14.04 (x86_64,CC=/localdata2/opt/gcc-4.9.4/bin/gcc-4.9)
> Ubuntu 14.04 (x86_64,CC=/localdata2/opt/gcc-5.4.0/bin/gcc-5.4)
> Ubuntu 14.04 (x86_64,CC=/localdata2/opt/gcc-6.2.0/bin/gcc-6.2)
> Ubuntu 14.04 (x86_64,CC=/localdata2/opt/gcc-7.0/bin/gcc-7.0)
> Ubuntu 14.04 (x86_64,CC=clang-3.9)
> Ubuntu 14.04 (x86_64,CC=clang-4.0)
> Ubuntu 14.04 (x86_64,CC=tcc)
> Ubuntu 15.04 (i686)
> Ubuntu 15.04 (x86_64)
> Ubuntu 16.04 (x86_64)
> gNewSense 3.0 (x86_64)
> kFreeBSD 9.0-2-amd64/Debian 7.8 (x86_64)
> openSUSE project 13.1 (x86_64)
Quite a menagerie.
Thanks for all of that testing!