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.

Full log


View this message in rfc822 format

From: Nix <nix <at> esperi.org.uk>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12820 <at> debbugs.gnu.org
Subject: 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)




This bug report was last modified 6 years and 181 days ago.

Previous Next


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