diffutils-devel
[Top][All Lists]
Advanced

[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!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]