--- Begin Message ---
|
Subject: |
test error and failures: tests/{du/long-from-unreadable.sh, rm/deep-2.sh} (exit status: 99/1) on Gentoo x86/amd64 |
|
Date: |
Mon, 6 Nov 2017 01:23:05 +0100 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Thunderbird/52.4.0 |
Hi,
we are seeing test _errors_ for tests/du/long-from-unreadable.sh on
Gentoo (amd64 and x86) in coreutils-8.28 and earlier.
I added some debug output to understand which Perl command is failing,
i.e. I changed
> $PERL \
> -e 'my $d = '$dir'; foreach my $i (1..52)' \
> -e ' { mkdir ($d, 0700) && chdir $d or die "$!" }' \
> || framework_failure_
into
> $PERL \
> -e 'my $d = '$dir'; foreach my $i (1..52) {' \
> -e ' mkdir ($d, 0700) or die "mkdir #$i failed: $!";' \
> -e ' chdir $d or die "chdir #$i failed: $!"' \
> -e '}' \
> || framework_failure_
Test output is:
> + perl -e 'my $d = xxxxxx; foreach my $i (1..52) {' -e ' mkdir ($d, 0700) or
> die "mkdir #$i failed: $!";' -e ' chdir $d or die "chdir #$i failed: $!"' -e
> '}'
> mkdir #42 failed: Numerical result out of range at -e line 2.
> + framework_failure_
> + warn_ 'long-from-unreadable.sh: set-up failure: '
> + case $IFS in
> + printf '%s\n' 'long-from-unreadable.sh: set-up failure: '
> long-from-unreadable.sh: set-up failure:
> + test 9 = 2
> + printf '%s\n' 'long-from-unreadable.sh: set-up failure: '
> + sed 1q
> + Exit 99
Full output: https://paste.pound-python.org/show/R4UTffgreKhF3l0wW1kO
/var/tmp/portage/sys-apps/coreutils-8.28/work is a LVM2 partition on top
of LUKS with XFS file format:
> # xfs_info /
> meta-data=/dev/dm-6 isize=512 agcount=4, agsize=9365248 blks
> = sectsz=512 attr=2, projid32bit=1
> = crc=1 finobt=1 spinodes=0 rmapbt=0
> = reflink=0
> data = bsize=4096 blocks=37460992, imaxpct=25
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=4096 ascii-ci=0 ftype=1
> log =internal bsize=4096 blocks=18291, version=2
> = sectsz=512 sunit=0 blks, lazy-count=1
> realtime =none extsz=4096 blocks=0, rtextents=0
Mount options:
> /dev/dm-6 on / type xfs (rw,relatime,attr2,inode64,noquota) [fsRoot]
No ACLs set for /var/tmp/portage/*.
But I am seeing the same test failure on ext3 without LVM2, LUKS..., too.
When I limit the loop to 40 for example, i.e. changing
> -e 'my $d = '$dir'; foreach my $i (1..52) {' \
into
> -e 'my $d = '$dir'; foreach my $i (1..40) {' \
the test will now _fail_ and no longer run into an error (shorted "x"):
> + perl -e 'my $d = xxxxxx; foreach my $i (1..40) {' -e ' mkdir ($d, 0700) or
> die "mkdir #$i failed: $!";' -e ' chdir $d or die "chdir #$i failed: $!"' -e
> '}'
> + mkdir inaccessible
> + cd inaccessible
> + chmod 0 .
> + du -s
> /var/tmp/portage/sys-apps/coreutils-8.28/work/coreutils-8.28/gt-long-from-unreadable.sh.B9nU/xxxxxx
> du: cannot read directory
> '/var/tmp/portage/sys-apps/coreutils-8.28/work/coreutils-8.28/gt-long-from-unreadable.sh.B9nU/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx/xxxxxx':
> File name too long
> + fail=1
> + Exit 1
Full output: https://paste.pound-python.org/show/u5JeETR7JiVWRRuIhRsw
Interesting, when I limit the loop to 19 the test will pass (failing
with >=20).
Test tests/rm/deep-2.sh is showing the same symptom: Test _error_
(EXIT 99) per default. But when limiting the loop to <=20 (yes, one more
than tests/du/long-from-unreadable.sh), it is passing...
Additional system details:
> Portage 2.3.13 (python 3.6.3-final-0, default/linux/amd64/13.0, gcc-6.4.0,
> glibc-2.25-r9, 4.4.96-gentoo x86_64)
> =================================================================
> System uname: address@hidden
> KiB Mem: 32844816 total, 11812012 free
> KiB Swap: 4194300 total, 4194300 free
> Timestamp of repository gentoo: Thu, 02 Nov 2017 21:25:09 +0000
> Head commit of repository gentoo: afa755339d59940753317eaf03ba710619ff33c9
>
> sh dash 0.5.9.1-r3
> ld GNU ld (Gentoo 2.29.1 p3) 2.29.1
> distcc 3.2rc1 x86_64-pc-linux-gnu [disabled]
> app-shells/bash: 4.4_p12::gentoo
> dev-lang/perl: 5.26.1-r1::gentoo
> dev-lang/python: 2.7.14::gentoo, 3.4.6::gentoo, 3.6.3::gentoo
> dev-util/cmake: 3.9.4::gentoo
> dev-util/pkgconfig: 0.29.2::gentoo
> sys-apps/baselayout: 2.4.1-r2::gentoo
> sys-apps/openrc: 0.34.5::gentoo
> sys-apps/sandbox: 2.12::gentoo
> sys-devel/autoconf: 2.69-r4::gentoo
> sys-devel/automake: 1.13.4-r1::gentoo, 1.15.1-r1::gentoo
> sys-devel/binutils: 2.29.1-r1::gentoo
> sys-devel/gcc: 6.4.0::gentoo
> sys-devel/gcc-config: 1.9.0::gentoo
> sys-devel/libtool: 2.4.6-r4::gentoo
> sys-devel/make: 4.2.1-r1::gentoo
> sys-kernel/linux-headers: 4.13::gentoo (virtual/os-headers)
> sys-libs/glibc: 2.25-r9::gentoo
--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#29164: Scratch this bug report |
|
Date: |
Mon, 6 Nov 2017 06:43:20 -0800 |
tags 29164 notabug
thanks
On Mon, Nov 6, 2017 at 12:21 AM, Thomas Deutschmann <address@hidden> wrote:
> please ignore this bug report. This is caused by Gentoo's sandbox in
> portage and no problem in coreutils. Sorry for wasting your time :/
Closing and marking as notabug
--- End Message ---