bug#12820: FWIW, this is still happening as of gnulib 4a82904

[Nix]

On 26 Feb 2013, Paul Eggert verbalised:

> On 02/26/13 13:48, Nix wrote:
>
>> #2  0x00000000004021e0 in test_utimens (address@hidden, 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)