GNU bug report logs - #12820
gnulib testsuite failure in latest master

Previous Next

Package: coreutils;

Reported by: Stefano Lattarini <stefano.lattarini <at> gmail.com>

Date: Wed, 7 Nov 2012 08:56:02 UTC

Severity: normal

Tags: moreinfo

Merged with 13894

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12820 in the body.
You can then email your comments to 12820 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#12820; Package coreutils. (Wed, 07 Nov 2012 08:56:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stefano Lattarini <stefano.lattarini <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Wed, 07 Nov 2012 08:56:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: gnulib testsuite failure in latest master
Date: Wed, 07 Nov 2012 09:55:28 +0100
[Message part 1 (text/plain, inline)]
On Debian, and with coreutils bootstrapped with bleeding-edge autotools.

Here are the details:

  $ autoconf --version | head -1
  autoconf (GNU Autoconf) 2.69.41-26cb

  $ git describe
  v8.20-17-g801cd62

  $ make check
  ...
  FAIL: test-utimens
  ...
  # TOTAL: 315
  # PASS:  300
  # SKIP:  14
  # XFAIL: 0
  # FAIL:  1
  # XPASS: 0
  # ERROR: 0

  $ cat gnulib-tests/test-utimens.log
  test-utimens.h:103: assertion failed

The config.log file is attached (compressed).  Let me know if you
need more information.

Regards,
  Stefano
[config.log.xz (application/octet-stream, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#12820; Package coreutils. (Wed, 07 Nov 2012 15:47:01 GMT) Full text and rfc822 format available.

Message #8 received at 12820 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12820 <at> debbugs.gnu.org
Subject: Re: bug#12820: gnulib testsuite failure in latest master
Date: Wed, 07 Nov 2012 07:46:52 -0800
Can you please run "strace ./test-utimens" and
let us know the system calls that the failing test
executes?




Information forwarded to bug-coreutils <at> gnu.org:
bug#12820; Package coreutils. (Wed, 07 Nov 2012 17:07:02 GMT) Full text and rfc822 format available.

Message #11 received at 12820 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12820 <at> debbugs.gnu.org
Subject: Re: bug#12820: gnulib testsuite failure in latest master
Date: Wed, 07 Nov 2012 18:06:13 +0100
tags 12820 + moreinfo
severity 12820 minor
thanks

Hi Paul.

On 11/07/2012 04:46 PM, Paul Eggert wrote:
> Can you please run "strace ./test-utimens" and
> let us know the system calls that the failing test
> executes?
>
Sure, here it is:

-*-*-

execve("./test-utimens", ["./test-utimens"], [/* 89 vars */]) = 0
brk(0)                                  = 0x981c000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb803b000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=197544, ...}) = 0
mmap2(NULL, 197544, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb800a000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/i686/cmov/librt.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\30\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=30684, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb8009000
mmap2(NULL, 33360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb8000000
mmap2(0xb8007000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xb8007000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240o\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1413288, ...}) = 0
mmap2(NULL, 1427832, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ea3000
mprotect(0xb7ff9000, 4096, PROT_NONE)   = 0
mmap2(0xb7ffa000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x156) = 0xb7ffa000
mmap2(0xb7ffd000, 10616, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ffd000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/i686/cmov/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220L\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=117009, ...}) = 0
mmap2(NULL, 98816, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e8a000
mmap2(0xb7e9f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) = 0xb7e9f000
mmap2(0xb7ea1000, 4608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ea1000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e89000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e898d0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7e9f000, 4096, PROT_READ)   = 0
mprotect(0xb7ffa000, 8192, PROT_READ)   = 0
mprotect(0xb8007000, 4096, PROT_READ)   = 0
mprotect(0xb8059000, 4096, PROT_READ)   = 0
munmap(0xb800a000, 197544)              = 0
set_tid_address(0xb7e89938)             = 6810
set_robust_list(0xb7e89940, 0xc)        = 0
futex(0xbfa0d810, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, bfa0d820) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0xb7e8e6e0, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0xb7e8eb70, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sys="Linux", node="bigio", ...}) = 0
rt_sigaction(SIGINT, {SIG_IGN, [], 0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], 0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0xbfa0d7e4) = 6811
waitpid(6811, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 6811
rt_sigaction(SIGINT, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
open("test-utimens.tfile", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 3
close(3)                                = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
open("test-utimens.ttmp", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 3
close(3)                                = 0
stat64("test-utimens.ttmp", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
unlink("test-utimens.ttmp")             = 0
nanosleep({0, 20000000}, NULL)          = 0
open("test-utimens.ttmp", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 3
close(3)                                = 0
stat64("test-utimens.ttmp", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
unlink("test-utimens.ttmp")             = 0
nanosleep({2, 0}, NULL)                 = 0
utimensat(AT_FDCWD, "test-utimens.tfile", NULL, 0) = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
clock_gettime(CLOCK_REALTIME, {1352305270, 38052554}) = 0
utimensat(AT_FDCWD, "test-utimens.tfile", {{1352305270, 38052554}, {1352305270, 38052554}}, 0) = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
utimensat(AT_FDCWD, "no_such", NULL, 0) = -1 ENOENT (No such file or directory)
utimensat(AT_FDCWD, "no_such/", NULL, 0) = -1 ENOENT (No such file or directory)
utimensat(AT_FDCWD, "", NULL, 0)        = -1 ENOENT (No such file or directory)
utimensat(AT_FDCWD, "test-utimens.tfile/", {{946684800, 0}, {946684800, 0}}, 0) = -1 ENOTDIR (Not a directory)
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
utimensat(AT_FDCWD, "test-utimens.tfile", {{946684800, 499999999}, {946684800, 999999999}}, 0) = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
utimensat(AT_FDCWD, "test-utimens.tfile", {{946684800, 0}, UTIME_NOW}, 0) = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
utimensat(AT_FDCWD, "test-utimens.tfile", {{1000000000, 0}, {1352305274, 0}}, 0) = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
symlink("test-utimens.tfile", "test-utimens.tlink") = 0
lstat64("test-utimens.tlink", {st_mode=S_IFLNK|0777, st_size=18, ...}) = 0
utimensat(AT_FDCWD, "test-utimens.tlink/", NULL, 0) = -1 ENOTDIR (Not a directory)
utimensat(AT_FDCWD, "test-utimens.tlink", {{946684800, 0}, {946684800, 0}}, 0) = 0
lstat64("test-utimens.tlink", {st_mode=S_IFLNK|0777, st_size=18, ...}) = 0
stat64("test-utimens.tlink", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
unlink("test-utimens.tlink")            = 0
unlink("test-utimens.tfile")            = 0
open("test-utimens.tfile", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 3
close(3)                                = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
open("test-utimens.tfile", O_WRONLY|O_LARGEFILE) = 3
utimensat(3, NULL, NULL, 0)             = 0
close(3)                                = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
clock_gettime(CLOCK_REALTIME, {1352305278, 41932970}) = 0
open("test-utimens.tfile", O_WRONLY|O_LARGEFILE) = 3
utimensat(3, NULL, {{1352305278, 41932970}, {1352305278, 41932970}}, 0) = 0
close(3)                                = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
open("no_such", O_WRONLY|O_LARGEFILE)   = -1 ENOENT (No such file or directory)
open("no_such", O_RDONLY|O_LARGEFILE)   = -1 ENOENT (No such file or directory)
utimensat(AT_FDCWD, "no_such", NULL, 0) = -1 ENOENT (No such file or directory)
open("no_such/", O_WRONLY|O_LARGEFILE)  = -1 ENOENT (No such file or directory)
open("no_such/", O_RDONLY|O_LARGEFILE)  = -1 ENOENT (No such file or directory)
utimensat(AT_FDCWD, "no_such/", NULL, 0) = -1 ENOENT (No such file or directory)
open("", O_WRONLY|O_LARGEFILE)          = -1 ENOENT (No such file or directory)
open("", O_RDONLY|O_LARGEFILE)          = -1 ENOENT (No such file or directory)
utimensat(AT_FDCWD, "", NULL, 0)        = -1 ENOENT (No such file or directory)
open("test-utimens.tfile", O_WRONLY|O_LARGEFILE) = 3
close(3)                                = 0
open("test-utimens.tfile", O_WRONLY|O_LARGEFILE) = 3
close(3)                                = 0
open("test-utimens.tfile/", O_WRONLY|O_LARGEFILE) = -1 ENOTDIR (Not a directory)
open("test-utimens.tfile/", O_RDONLY|O_LARGEFILE) = -1 ENOTDIR (Not a directory)
utimensat(AT_FDCWD, "test-utimens.tfile/", {{946684800, 0}, {946684800, 0}}, 0) = -1 ENOTDIR (Not a directory)
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
open("test-utimens.tfile", O_WRONLY|O_LARGEFILE) = 3
utimensat(3, NULL, {{946684800, 499999999}, {946684800, 999999999}}, 0) = 0
close(3)                                = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
open("test-utimens.tfile", O_WRONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
utimensat(3, NULL, {{946684800, 0}, UTIME_NOW}, 0) = 0
close(3)                                = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
open("test-utimens.tfile", O_WRONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
utimensat(3, NULL, {{1000000000, 0}, {1352305282, 0}}, 0) = 0
close(3)                                = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
symlink("test-utimens.tfile", "test-utimens.tlink") = 0
lstat64("test-utimens.tlink", {st_mode=S_IFLNK|0777, st_size=18, ...}) = 0
open("test-utimens.tlink/", O_WRONLY|O_LARGEFILE) = -1 ENOTDIR (Not a directory)
open("test-utimens.tlink/", O_RDONLY|O_LARGEFILE) = -1 ENOTDIR (Not a directory)
utimensat(AT_FDCWD, "test-utimens.tlink/", NULL, 0) = -1 ENOTDIR (Not a directory)
open("test-utimens.tlink", O_WRONLY|O_LARGEFILE) = 3
utimensat(3, NULL, {{946684800, 0}, {946684800, 0}}, 0) = 0
close(3)                                = 0
lstat64("test-utimens.tlink", {st_mode=S_IFLNK|0777, st_size=18, ...}) = 0
stat64("test-utimens.tlink", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
unlink("test-utimens.tlink")            = 0
unlink("test-utimens.tfile")            = 0
open("test-utimens.tfile", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 3
fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
utimensat(3, NULL, NULL, 0)             = 0
fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
clock_gettime(CLOCK_REALTIME, {1352305286, 46894728}) = 0
utimensat(3, NULL, {{1352305286, 46894728}, {1352305286, 46894728}}, 0) = 0
fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
utimensat(99, NULL, NULL, 0)            = -1 EBADF (Bad file descriptor)
dup(0)                                  = 4
close(4)                                = 0
utimensat(4, NULL, NULL, 0)             = -1 EBADF (Bad file descriptor)
fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
utimensat(3, NULL, {{946684800, 499999999}, {946684800, 999999999}}, 0) = 0
fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
utimensat(3, NULL, {{946684800, 0}, UTIME_NOW}, 0) = 0
fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
utimensat(3, NULL, {{1000000000, 0}, {1352305290, 0}}, 0) = 0
fstat64(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
close(3)                                = 0
unlink("test-utimens.tfile")            = 0
utimensat(AT_FDCWD, "no_such", NULL, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory)
utimensat(AT_FDCWD, "no_such/", NULL, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory)
utimensat(AT_FDCWD, "", NULL, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory)
open("test-utimens.tfile", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 3
close(3)                                = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
utimensat(AT_FDCWD, "test-utimens.tfile/", {{946684800, 0}, {946684800, 0}}, AT_SYMLINK_NOFOLLOW) = -1 ENOTDIR (Not a directory)
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
utimensat(AT_FDCWD, "test-utimens.tfile", {{946684800, 0}, {946684800, 0}}, AT_SYMLINK_NOFOLLOW) = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
symlink("test-utimens.tfile", "test-utimens.tlink") = 0
utimensat(AT_FDCWD, "test-utimens.tlink", NULL, AT_SYMLINK_NOFOLLOW) = 0
stat64("test-utimens.tfile", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
lstat64("test-utimens.tlink", {st_mode=S_IFLNK|0777, st_size=18, ...}) = 0
unlink("test-utimens.tfile")            = 0
lstat64("test-utimens.tlink", {st_mode=S_IFLNK|0777, st_size=18, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
lstat64("test-utimens.tlink", {st_mode=S_IFLNK|0777, st_size=18, ...}) = 0
lstat64("test-utimens.tlink", {st_mode=S_IFLNK|0777, st_size=18, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
utimensat(AT_FDCWD, "test-utimens.tlink", {{946684800, 499999999}, {946684800, 999999999}}, AT_SYMLINK_NOFOLLOW) = 0
lstat64("test-utimens.tlink", {st_mode=S_IFLNK|0777, st_size=18, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
lstat64("test-utimens.tlink", {st_mode=S_IFLNK|0777, st_size=18, ...}) = 0
utimensat(AT_FDCWD, "test-utimens.tlink", {{946684800, 0}, UTIME_NOW}, AT_SYMLINK_NOFOLLOW) = 0
lstat64("test-utimens.tlink", {st_mode=S_IFLNK|0777, st_size=18, ...}) = 0
nanosleep({2, 0}, NULL)                 = 0
lstat64("test-utimens.tlink", {st_mode=S_IFLNK|0777, st_size=18, ...}) = 0
utimensat(AT_FDCWD, "test-utimens.tlink", {{1000000000, 0}, {1352305300, 0}}, AT_SYMLINK_NOFOLLOW) = 0
lstat64("test-utimens.tlink", {st_mode=S_IFLNK|0777, st_size=18, ...}) = 0
unlink("test-utimens.tlink")            = 0
symlink("test-utimens.tdir", "test-utimens.tlink") = 0
mkdir("test-utimens.tdir", 0700)        = 0
utimensat(AT_FDCWD, "test-utimens.tlink/", {{946684800, 0}, {946684800, 0}}, AT_SYMLINK_NOFOLLOW) = 0
stat64("test-utimens.tdir", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lstat64("test-utimens.tlink", {st_mode=S_IFLNK|0777, st_size=17, ...}) = 0
utimensat(AT_FDCWD, "test-utimens.tlink", NULL, AT_SYMLINK_NOFOLLOW) = 0
stat64("test-utimens.tdir", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lstat64("test-utimens.tlink", {st_mode=S_IFLNK|0777, st_size=17, ...}) = 0
rmdir("test-utimens.tdir")              = 0
unlink("test-utimens.tlink")            = 0
exit_group(0)                           =

-*-*-

And I couldn't but notice that the test had passed this time ...

So I tried to re-run it from "make check", and passed this time as well.
Weird.  Let's see if I can reproduce the failure with:

  $ i=0; while strace -o ut ./test-utimens; do echo RUN $((++i)); done

... Well, I still haven't reproduced it after 47 runs.  I'll let you
know if I manage to reproduce it somehow.  In the meantime, I've taken
the liberty of tagging my report with "moreinfo".

Regards,
  Stefano




Added tag(s) moreinfo. Request was from Stefano Lattarini <stefano.lattarini <at> gmail.com> to control <at> debbugs.gnu.org. (Wed, 07 Nov 2012 17:07:02 GMT) Full text and rfc822 format available.

Severity set to 'minor' from 'normal' Request was from Stefano Lattarini <stefano.lattarini <at> gmail.com> to control <at> debbugs.gnu.org. (Wed, 07 Nov 2012 17:07:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-coreutils <at> gnu.org:
bug#12820; Package coreutils. (Wed, 07 Nov 2012 18:06:02 GMT) Full text and rfc822 format available.

Message #18 received at 12820 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12820 <at> debbugs.gnu.org
Subject: Re: bug#12820: gnulib testsuite failure in latest master
Date: Wed, 07 Nov 2012 19:05:46 +0100
>On 11/07/2012 06:06 PM, Stefano Lattarini wrote:

> Let's see if I can reproduce the failure with:
> 
>   $ i=0; while strace -o ut ./test-utimens; do echo RUN $((++i)); done
> 
> ... Well, I still haven't reproduced it after 47 runs.
>
Nor after 150 runs.  I'll stop trying to reproduce it for the moment;
I'll get back to this thread if the issue crops up again, or if someone
has suggestions about how to (try to) reproduce it.

Regards,
  Stefano




Information forwarded to bug-coreutils <at> gnu.org:
bug#12820; Package coreutils. (Wed, 07 Nov 2012 18:29:01 GMT) Full text and rfc822 format available.

Message #21 received at 12820 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12820 <at> debbugs.gnu.org
Subject: Re: bug#12820: gnulib testsuite failure in latest master
Date: Wed, 07 Nov 2012 10:28:38 -0800
On 11/07/2012 09:06 AM, Stefano Lattarini wrote:

> stat64("test-utimens.ttmp", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> unlink("test-utimens.ttmp")             = 0
> nanosleep({0, 20000000}, NULL)          = 0
> open("test-utimens.ttmp", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 3
> close(3)                                = 0
> stat64("test-utimens.ttmp", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> unlink("test-utimens.ttmp")             = 0
> nanosleep({2, 0}, NULL)                 = 0

Well, there's something funny going on there, as this indicates that
your files' time stamps have only 1-second or even 2-second
resolution.  Were you running in a FAT file system or something like
that?  That might explain the problem.  If you were running in an
ordinary file system like ext4, the above is a bug and should get
tracked down and fixed.




Information forwarded to bug-coreutils <at> gnu.org:
bug#12820; Package coreutils. (Wed, 07 Nov 2012 18:33:02 GMT) Full text and rfc822 format available.

Message #24 received at 12820 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12820 <at> debbugs.gnu.org
Subject: Re: bug#12820: gnulib testsuite failure in latest master
Date: Wed, 07 Nov 2012 19:32:04 +0100
On 11/07/2012 07:28 PM, Paul Eggert wrote:
> On 11/07/2012 09:06 AM, Stefano Lattarini wrote:
> 
>> stat64("test-utimens.ttmp", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
>> unlink("test-utimens.ttmp")             = 0
>> nanosleep({0, 20000000}, NULL)          = 0
>> open("test-utimens.ttmp", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 3
>> close(3)                                = 0
>> stat64("test-utimens.ttmp", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
>> unlink("test-utimens.ttmp")             = 0
>> nanosleep({2, 0}, NULL)                 = 0
> 
> Well, there's something funny going on there, as this indicates that
> your files' time stamps have only 1-second or even 2-second
> resolution.  Were you running in a FAT file system or something like
> that?
>
Nope, ext3:

  $ pwd
  /devel/bleeding/src/coreutils/gnulib-tests
  $ df -T .
  Filesystem     Type 1K-blocks     Used Available Use% Mounted on
  /dev/hdb4      ext3  23293824 13885728   9408096  60% /devel

Exact kernel version:

  $ uname -r
  2.6.30-2-686

(and not custom compiled, but installed from Debian package).

> That might explain the problem.  If you were running in an
> ordinary file system like ext4, the above is a bug and should get
> tracked down and fixed.
>

HTH,
  Stefano





Information forwarded to bug-coreutils <at> gnu.org:
bug#12820; Package coreutils. (Thu, 08 Nov 2012 07:04:01 GMT) Full text and rfc822 format available.

Message #27 received at 12820 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 12820 <at> debbugs.gnu.org
Subject: Re: bug#12820: gnulib testsuite failure in latest master
Date: Thu, 08 Nov 2012 08:03:21 +0100
Stefano Lattarini wrote:

>>On 11/07/2012 06:06 PM, Stefano Lattarini wrote:
>
>> Let's see if I can reproduce the failure with:
>>
>>   $ i=0; while strace -o ut ./test-utimens; do echo RUN $((++i)); done
>>
>> ... Well, I still haven't reproduced it after 47 runs.
>>
> Nor after 150 runs.  I'll stop trying to reproduce it for the moment;
> I'll get back to this thread if the issue crops up again, or if someone
> has suggestions about how to (try to) reproduce it.

Thanks for reporting this.
I've seen similar failures a few times over the years, but not in the
last several months -- that are extremely hard to reproduce.
For me, they seemed more likely to appear when doing massively-parallel
"make check".




Information forwarded to bug-coreutils <at> gnu.org:
bug#12820; Package coreutils. (Thu, 08 Nov 2012 07:45:01 GMT) Full text and rfc822 format available.

Message #30 received at 12820 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: bug-gnulib <bug-gnulib <at> gnu.org>, 12820 <at> debbugs.gnu.org
Subject: Re: bug#12820: gnulib testsuite failure in latest master
Date: Wed, 07 Nov 2012 23:44:49 -0800
Ouch, I read your strace output incorrectly: it was napping
for 20 ms, not 2 s.  Still, there should be no need to nap
for that long; 1 ms should suffice on your platform.

I installed the following patch to cause the test
to take shorter naps.  This might affect your original
problem, and might not (hey! it's a timing problem)
but at least it should make the test run faster.

From b1af052298f85650d85ea37d24f59ab99ff56db8 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Wed, 7 Nov 2012 23:36:43 -0800
Subject: [PATCH] test-utimens: speed up by taking shorter naps

* tests/nap.h (lt_mtime, get_mtime, nap_works, guess_delay):
New functions.
(nap): Use them, to do a better job of guessing the delay.
On Fedora 17 with ext4 atop md atop hard disks, this made
test-utimens run 10x faster, because the test napped for
1 ms at a time rather than 20 ms.  Reported by Stefano Lattarini in
<http://bugs.gnu.org/12820#11>.
---
 ChangeLog   |  11 +++++++
 tests/nap.h | 107 ++++++++++++++++++++++++++++++++++++++++--------------------
 2 files changed, 83 insertions(+), 35 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 1a1e8b7..bd05f3c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2012-11-07  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	test-utimens: speed up by taking shorter naps
+	* tests/nap.h (lt_mtime, get_mtime, nap_works, guess_delay):
+	New functions.
+	(nap): Use them, to do a better job of guessing the delay.
+	On Fedora 17 with ext4 atop md atop hard disks, this made
+	test-utimens run 10x faster, because the test napped for
+	1 ms at a time rather than 20 ms.  Reported by Stefano Lattarini in
+	<http://bugs.gnu.org/12820#11>.
+
 2012-11-07  Jim Meyering  <jim <at> meyering.net>
 
 	mountlist.c: fix a compilation failure
diff --git a/tests/nap.h b/tests/nap.h
index 6dfb0a0..99d47b6 100644
--- a/tests/nap.h
+++ b/tests/nap.h
@@ -19,48 +19,85 @@
 #ifndef GLTEST_NAP_H
 # define GLTEST_NAP_H
 
+static int
+lt_mtime (struct stat const *a, struct stat const *b)
+{
+  time_t as = a->st_mtime;
+  time_t bs = b->st_mtime;
+  int ans = get_stat_mtime_ns (a);
+  int bns = get_stat_mtime_ns (b);
+
+  return as < bs || (as == bs && ans < bns);
+}
+
+static void
+get_mtime (int fd, struct stat *st, int do_write)
+{
+  if (do_write)
+    ASSERT (write (fd, "\n", 1) == 1);
+  ASSERT (fstat (fd, st) == 0);
+}
+
+/* Given a file whose descriptor is FD, see whether delaying by DELAY
+   microseconds causes a change in a file's time stamp.  If the time
+   stamps differ, repeat the test one more time, in case we crossed a
+   quantization boundary on a file system with lower resolution.  *ST
+   is the file's status, recently gotten.  Update *ST to reflect the
+   latest status gotten.  */
+static int
+nap_works (int fd, int delay, struct stat *st)
+{
+  struct stat old_st;
+  int result = 0;
+  old_st = *st;
+  usleep (delay);
+  get_mtime (fd, st, 1);
+  if (! lt_mtime (&old_st, st))
+    return 0;
+  old_st = *st;
+  usleep (delay);
+  get_mtime (fd, st, 1);
+  return lt_mtime (&old_st, st);
+}
+
+static int
+guess_delay (void)
+{
+  /* Try a 1-microsecond sleep first, for speed.  If that doesn't
+     work, try a 1 ms sleep; that should work with ext.  If it doesn't
+     work, try a 20 ms sleep.  xfs has a quantization of about 10
+     milliseconds, even though it has a granularity of 1 nanosecond,
+     and NTFS has a default quantization of 15.25 milliseconds, even
+     though it has a granularity of 100 nanoseconds, so 20 ms is a
+     good quantization to try.  If that doesn't work, try 1 second.
+     The worst case is 2 seconds, needed for FAT.  */
+  static int const delaytab[] = {1, 1000, 20000, 1000000 };
+  int fd = creat (BASE "tmp", 0600);
+  int i;
+  int delay = 2000000;
+  struct stat st;
+  ASSERT (0 <= fd);
+  get_mtime (fd, &st, 0);
+  for (i = 0; i < sizeof delaytab / sizeof delaytab[0]; i++)
+    if (nap_works (fd, delaytab[i], &st))
+      {
+        delay = delaytab[i];
+        break;
+      }
+  ASSERT (close (fd) == 0);
+  ASSERT (unlink (BASE "tmp") == 0);
+  return delay;
+}
+
 /* Sleep long enough to notice a timestamp difference on the file
    system in the current directory.  Assumes that BASE is defined,
    and requires that the test module depends on usleep.  */
 static void
 nap (void)
 {
-  static long delay;
+  static int delay;
   if (!delay)
-    {
-      /* Initialize only once, by sleeping for 20 milliseconds (needed
-         since xfs has a quantization of about 10 milliseconds, even
-         though it has a granularity of 1 nanosecond, and since NTFS
-         has a default quantization of 15.25 milliseconds, even though
-         it has a granularity of 100 nanoseconds).  If the seconds
-         differ, repeat the test one more time (in case we crossed a
-         quantization boundary on a file system with 1 second
-         resolution).  If we can't observe a difference in only the
-         nanoseconds, then fall back to 1 second if the time is odd,
-         and 2 seconds (needed for FAT) if time is even.  */
-      struct stat st1;
-      struct stat st2;
-      ASSERT (close (creat (BASE "tmp", 0600)) == 0);
-      ASSERT (stat (BASE "tmp", &st1) == 0);
-      ASSERT (unlink (BASE "tmp") == 0);
-      delay = 20000;
-      usleep (delay);
-      ASSERT (close (creat (BASE "tmp", 0600)) == 0);
-      ASSERT (stat (BASE "tmp", &st2) == 0);
-      ASSERT (unlink (BASE "tmp") == 0);
-      if (st1.st_mtime != st2.st_mtime)
-        {
-          /* Seconds differ, give it one more shot.  */
-          st1 = st2;
-          usleep (delay);
-          ASSERT (close (creat (BASE "tmp", 0600)) == 0);
-          ASSERT (stat (BASE "tmp", &st2) == 0);
-          ASSERT (unlink (BASE "tmp") == 0);
-        }
-      if (! (st1.st_mtime == st2.st_mtime
-             && get_stat_mtime_ns (&st1) < get_stat_mtime_ns (&st2)))
-        delay = (st1.st_mtime & 1) ? 1000000 : 2000000;
-    }
+    delay = guess_delay ();
   usleep (delay);
 }
 
-- 
1.7.11.7






Information forwarded to bug-coreutils <at> gnu.org:
bug#12820; Package coreutils. (Thu, 08 Nov 2012 09:03:01 GMT) Full text and rfc822 format available.

Message #33 received at 12820 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: bug-gnulib <bug-gnulib <at> gnu.org>, 12820 <at> debbugs.gnu.org
Subject: Re: bug#12820: gnulib testsuite failure in latest master
Date: Thu, 08 Nov 2012 10:02:24 +0100
On 11/08/2012 08:44 AM, Paul Eggert wrote:
> Ouch, I read your strace output incorrectly: it was napping
> for 20 ms, not 2 s.  Still, there should be no need to nap
> for that long; 1 ms should suffice on your platform.
> 
> I installed the following patch to cause the test
> to take shorter naps.  This might affect your original
> problem, and might not (hey! it's a timing problem)
> but at least it should make the test run faster.
> 
I'll re-run the affected test case as soon as coreutils updates
its version of gnulib then, and see what happens.

Thanks,
  Stefano




Information forwarded to bug-coreutils <at> gnu.org:
bug#12820; Package coreutils. (Tue, 26 Feb 2013 21:51:02 GMT) Full text and rfc822 format available.

Message #36 received at 12820 <at> debbugs.gnu.org (full text, mbox):

From: Nix <nix <at> esperi.org.uk>
To: 12820 <at> debbugs.gnu.org
Subject: FWIW, this is still happening as of gnulib 4a82904
Date: Tue, 26 Feb 2013 21:48:55 +0000
I just got this (from utimensat, not utimens, but they share a lot of
code) while doing a massively parallel 'make check' of coreutils 8.21 on
Linux 3.7.

The filesystem in question is ext4 atop loopback atop LVM atop md
(raid1), a fairly typical setup for coreutils test runs, I'd think. (The
source tree is ultimately mounted over NFSv3 and gnulib bootstrapped
there, but that shouldn't matter because the first thing I do after that
is cp -a the whole thing into the loopback filesystem and then
configure, build, and test from there.)

#0  0x00007f6bd07858f5 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x00007f6bd07858f5 in raise () from /lib/libc.so.6
#1  0x00007f6bd07889fb in __GI_abort () at abort.c:92
#2  0x00000000004021e0 in test_utimens (print=print <at> entry=true, func=0x401890 <do_utimensat>) at test-utimens.h:35
#3  0x0000000000401449 in main () at test-utimensat.c:86

As before, it's not reproducible on demand (e.g. under a debugger).




Information forwarded to bug-coreutils <at> gnu.org:
bug#12820; Package coreutils. (Tue, 26 Feb 2013 22:09:01 GMT) Full text and rfc822 format available.

Message #39 received at 12820 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Nix <nix <at> esperi.org.uk>
Cc: 12820 <at> debbugs.gnu.org
Subject: Re: bug#12820: FWIW, this is still happening as of gnulib 4a82904
Date: Tue, 26 Feb 2013 14:06:22 -0800
On 02/26/13 13:48, Nix wrote:

> #2  0x00000000004021e0 in test_utimens (print=print <at> entry=true, func=0x401890 <do_utimensat>) at test-utimens.h:35

If that line number is right, the test program
did a creat (file, 0600) that succeeded, followed
by a stat (file, &st) that failed.  Offhand the only
way I can see that happening, other than a bug in
the underlying system or a weird resource failure
or some other process mucking things up, is if
you're running a 32-bit application and the file
system assigned a big inode number to the file, so
large that it won't fit in 32 bits.  Is that possible?
(If so, don't do that.  :-)





Information forwarded to bug-coreutils <at> gnu.org:
bug#12820; Package coreutils. (Tue, 26 Feb 2013 22:29:01 GMT) Full text and rfc822 format available.

Message #42 received at 12820 <at> debbugs.gnu.org (full text, mbox):

From: Nix <nix <at> esperi.org.uk>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12820 <at> debbugs.gnu.org
Subject: Re: bug#12820: FWIW, this is still happening as of gnulib 4a82904
Date: Tue, 26 Feb 2013 22:26:20 +0000
On 26 Feb 2013, Paul Eggert verbalised:

> On 02/26/13 13:48, Nix wrote:
>
>> #2  0x00000000004021e0 in test_utimens (print=print <at> entry=true, func=0x401890 <do_utimensat>) at test-utimens.h:35
>
> If that line number is right, the test program
> did a creat (file, 0600) that succeeded, followed
> by a stat (file, &st) that failed.  Offhand the only
> way I can see that happening, other than a bug in
> the underlying system or a weird resource failure
> or some other process mucking things up, is if
> you're running a 32-bit application and the file
> system assigned a big inode number to the file, so
> large that it won't fit in 32 bits.  Is that possible?

Nope, this was a 64-bit build. It's mysterious to me as well. A bug in
the underlying system is not beyond the bounds of possibility!

I'll run the gnulib parallel tests in a tight loop overnight, in the
same environment, and see if I can make it happen again. If it can, it's
time to figure out how to reproduce it under gdb: I guess running the
gnulib tests in a tight loop and then running this test in a tight loop
under gdb until it dies might work.

-- 
NULL && (void)




Information forwarded to bug-coreutils <at> gnu.org:
bug#12820; Package coreutils. (Wed, 27 Feb 2013 18:28:02 GMT) Full text and rfc822 format available.

Message #45 received at 12820 <at> debbugs.gnu.org (full text, mbox):

From: Nix <nix <at> esperi.org.uk>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12820 <at> debbugs.gnu.org
Subject: Re: bug#12820: FWIW, this is still happening as of gnulib 4a82904
Date: Wed, 27 Feb 2013 18:25:44 +0000
On 26 Feb 2013, Paul Eggert outgrape:

> On 02/26/13 13:48, Nix wrote:
>
>> #2  0x00000000004021e0 in test_utimens (print=print <at> entry=true, func=0x401890 <do_utimensat>) at test-utimens.h:35
>
> If that line number is right, the test program
> did a creat (file, 0600) that succeeded, followed
> by a stat (file, &st) that failed.

Looks like it.

Running test-utimensat in a tight loop shows frequent assertion
failures: running it under high load (e.g. while a 'make -j 9 check' is
running) shows fewer:

No load:

% START=$(date +%s); while [[ $(($(date +%s)-$START)) -lt 10 ]]; do ./test-utimensat; done
test-lutimens.h:162: assertion failed
test-lutimens.h:162: assertion failed
test-utimens.h:103: assertion failed
test-utimens.h:41: assertion failed
test-lutimens.h:162: assertion failed

Parallel make -j 9 check:

% START=$(date +%s); while [[ $(($(date +%s)-$START)) -lt 10 ]]; do ./test-utimensat; done
test-utimens.h:113: assertion failed
test-utimens.h:37: assertion failed
test-utimens.h:130: assertion failed
test-utimens.h:113: assertion failed
test-utimens.h:103: assertion failed
test-lutimens.h:64: assertion failed
test-utimens.h:128: assertion failed
test-utimens.h:103: assertion failed
test-lutimens.h:64: assertion failed

I note that this is not exactly healthy hardware: it is has a slowly
failing fan and is going in for repair tomorrow. However it isn't
overheating yet and *did* just complete a GCC LTO bootstrap-and-test
with no FAILs I wasn't expecting so I don't think the fan failure is
likely to be the cause of these assertions.

As is typical of timing-related faults, running it under strace makes
the frequency of the problems plunge. I've stuck a tarball of all the
distinct failing straces I could get in a few hours of tight loops under
strace up at
<http://www.esperi.org.uk/~nix/bugs/gnulib/utimensat.tar.gz>. (I
truncated the execve lines because dumping my entire process environment
out in public is not something I'm entirely happy doing. Paranoia,
maybe. :) )


Classifying the small set of assertion failures above (a set small
enough that I felt I could attack it without dying of boredom), we see:

test-utimens.h:37: assertion failed
  ASSERT (func (BASE "file", NULL) == 0);

test-utimens.h:113: assertion failed
  ASSERT (st3.st_atime == Y2K);

test-utimens.h:128: assertion failed
  ASSERT (get_stat_mtime_ns (&st3) == get_stat_mtime_ns (&st2));

test-lutimens.h:64: assertion failed
test-lutimens.h:162: assertion failed
test-utimens.h:41: assertion failed
test-utimens.h:103: assertion failed
test-utimens.h:130: assertion failed
  ASSERT (ctime_compare (&st1, &st2) < 0);
  ASSERT (ctime_compare (&st2, &st3) < 0);

I thought it was worth my analyzing at least the largest set of
failures, this one. This is simply a race. When these assertions are
hit, I see things like this:

st1.st_ctime: 1361977729; st2.st_ctime: 1361977729; compare: 0; get_stat_ctime_ns(st1): 613474299, get_stat_ctime_ns(st2): 613474299

i.e. the nsec values are identical. This is surely valid: it just means
the two stats were carried out in the same 1ns interval. All these
asserts should be <= 0. (I just saw an identical failure in
test-lchown.h:112.)




Information forwarded to bug-coreutils <at> gnu.org:
bug#12820; Package coreutils. (Thu, 28 Feb 2013 17:11:02 GMT) Full text and rfc822 format available.

Message #48 received at 12820 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Nix <nix <at> esperi.org.uk>
Cc: 12820 <at> debbugs.gnu.org
Subject: Re: bug#12820: FWIW, this is still happening as of gnulib 4a82904
Date: Thu, 28 Feb 2013 09:08:50 -0800
On 02/27/13 10:25, Nix wrote:
> st1.st_ctime: 1361977729; st2.st_ctime: 1361977729; compare: 0; get_stat_ctime_ns(st1): 613474299, get_stat_ctime_ns(st2): 613474299
> 
> i.e. the nsec values are identical. This is surely valid: it just means
> the two stats were carried out in the same 1ns interval. All these
> asserts should be <= 0. 

No, because there's a "nap ()" in between, which means
the time stamps can't possibly be generated in the same
1 ns interval, at least, not if nap () is working.

Perhaps there's a bug in nap () but if so the bug should
be fixed there.




Forcibly Merged 12820 13894. Request was from Pádraig Brady <P <at> draigBrady.com> to control <at> debbugs.gnu.org. (Thu, 07 Mar 2013 01:35:03 GMT) Full text and rfc822 format available.

Information forwarded to bug-coreutils <at> gnu.org:
bug#12820; Package coreutils. (Fri, 18 Jan 2019 06:09:01 GMT) Full text and rfc822 format available.

Message #53 received at 12820 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Nix <nix <at> esperi.org.uk>
Cc: 12820 <at> debbugs.gnu.org
Subject: Re: bug#12820: FWIW, this is still happening as of gnulib 4a82904
Date: Thu, 17 Jan 2019 23:07:55 -0700
close 12820
stop

(triaging old bugs)

Hello,

On 2013-02-28 10:08 a.m., Paul Eggert wrote:
> 
> Perhaps there's a bug in nap () but if so the bug should
> be fixed there.
> 

Given the above, and with no further comments in almost 6 years,
I'm closing this bug.

Discussion can continue by replying to this thread.
 - assaf






bug closed, send any further explanations to 12820 <at> debbugs.gnu.org and Stefano Lattarini <stefano.lattarini <at> gmail.com> Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Fri, 18 Jan 2019 06:09:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 15 Feb 2019 12:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 5 years and 43 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.